Guide

What a security scanner cannot detect from outside your app

Every external scanner has blind spots, and most vendors do not publish theirs. Ours are below: 14 checks we cannot perform at all, 3 we infer rather than test, and 16 that require your permission before they run. If you are choosing a scanner, these are the questions to ask whoever you pick.

The three tiers of certainty

Not every finding is equally solid, and a report that presents them as if they were is misleading you. We sort every check into one of three tiers and say which one produced each result.

If we say a service_role key is in your bundle, we matched it in the file.

Observed

Read directly from what your app already sends the browser: the HTML, the JavaScript files the page references, the response headers, the TLS handshake. If we say a service_role key is in your bundle, we matched it in the file. There is no interpretation involved and no request to anything private. This is the bedrock, and it is where most real findings come from.

Not determinable from outside

Your Supabase publishable key being visible is normal and expected. Whether the tables behind it are locked down is the question that matters, and answering it means querying your database. On a domain we cannot prove you own, sending that query is an unauthorised request to someone else's system, whatever it returns. Reading a public JavaScript file is what every browser does a billion times a day. Using a key found inside it to query a database is a different act, and the distinction is not a technicality.

So we report the exposure and say plainly that the policy behind it was not tested. A scanner that tells you your tables are readable, without you having proved ownership, queried a database it had no permission to touch.

Inferred

Three of our checks are derived from other findings rather than tested. An open read usually implies open writes, because the same missing policy governs both — but "usually" is not "confirmed", and we never insert or delete a row to find out. These are labelled as inference and contribute nothing to your score.

The 14 checks we cannot perform

These need credentials and multi-step interaction with a running app. No external scan can do them, ours included, and any scanner claiming otherwise on a URL alone is worth a follow-up question:

• Auth flow tracing
• Token expiry and refresh behaviour
• Password reset flow
• Email verification bypass
• Role escalation paths
• Endpoint chain analysis
• Business rule probes
• Rate limit probing
• CSRF token coverage
• Open redirect parameters
• Directory listing
• Backup and config file exposure
• Verbose error disclosure
• Default credential probes

They emit nothing. They are not counted in any total we advertise.

Why "no issues found" is not "secure"

A clean result means nothing was found in the checks that ran. It does not mean there is nothing there. Your app may have a flaw in a category above, in code paths behind a login, or in a file the page never references so we never fetched it.

We will never render the word "secure" as a verdict, and neither should any tool you rely on. The honest sentence is longer and less satisfying: we looked at these things, and in these things we found nothing.

What to ask any scanner you are considering

• Which findings did you confirm, and which did you infer?
• Did you query my database? If so, on what authority — and would you do that to a domain I do not own?
• What did you look for and not find? A report listing only hits is marketing, not research.
• What can you not check at all?
• How is the score calculated, and does an unconfirmed finding cost the same as a confirmed one?

Good answers to those five are worth more than a bigger number of advertised checks.

Frequently asked

Can a security scanner tell me if my app is safe?

No. It can tell you what it found in what it tested. Safety is a broader claim than any external tool can support, and a scanner presenting a clean result as proof of safety is overstating what it did.

Why does the report say "may be readable" instead of "is readable"?

Because we did not query your database. Confirming it would mean sending a real request to your infrastructure, which we only do once you have proved you own the domain. Until then the honest phrasing is the uncertain one.

Does this mean the scan is not worth running?

The opposite. The faults AI code generators most often ship — a database key in the browser bundle, a service-role key in client code, missing security headers, published source maps — are all in the observed tier. They are the most common serious problems and the most reliably detectable. Knowing the edges of a tool is what lets you trust the middle of it.