Profile

Florian.
Passive application security for sensitive data.

I work from the same angle an attacker uses during reconnaissance, without crossing the red line. The goal is not to ship a generic PDF. It is to identify what is actually exposed, prove it cleanly, and hand you a remediation path your product or engineering team can act on.

Markers

100%
passive
48h
initial report
1 cmd
reproducible proof
4+
sensitive sectors

What I actually do

Approach

Read-only, attacker-view analysis

I start from the public surface: subdomains, JavaScript bundles, endpoints, auth flows, buckets, webhooks, technical docs, and exposed back offices. No server access, no privileged accounts.

Proof

Findings that hold up

Every flaw I keep has to be reproducible, understandable, and tied to business impact. If something cannot be cleanly verified, it stays a hypothesis and is labelled as one.

Context

Technical and regulatory reading

Exposures are not ranked on technical severity alone. They are framed against GDPR, HDS, DORA, PCI-DSS, or enterprise-customer context when it matters.

Output

Remediation the team can use

The deliverable is built for action: what is exposed, why it matters, what to fix first, and how to explain the risk to a CTO, founder, or client.

What shapes the method

Recent audits across training platforms, legaltech products, business portals, and data tools keep converging on the same weak points.

  • JavaScript bundles and source maps that reveal auth flows, roles, data models, or admin endpoints.
  • Swagger, GraphQL, and public API documentation that let an outsider rebuild the business logic.
  • Missing or incomplete RLS on Supabase/PostgreSQL, letting accounts read, update, or delete data they should not touch.
  • n8n, Make, or in-house webhooks exposed client-side and callable without proper authentication or signature checks.
  • Back offices, IAM components, analytics tools, or operator surfaces left publicly reachable when they should be tightly segmented.

Who CleanIssue is for

  • SMBs and startups handling sensitive data without a fully structured security team yet.
  • CTOs and founders who need to put a number on a concrete risk before remediation, a client audit, or a fundraise.
  • Product teams that want a fast diagnosis before a data exposure turns into an incident.
  • Regulated or trust-sensitive environments where proof of due diligence matters as much as security itself: healthtech, fintech, legaltech, SaaS, HR, training.

Read next

FAQ

Need an external review of your HR SaaS?

Share your product, stack, and client context. We will come back with the right review scope.

Discuss your audit