A public-surface URL check can prove what the deployed page returned to an ordinary visitor. It cannot prove how private server-side controls behave. That boundary is what makes a free scan both safe and useful: confirmed public evidence is immediate, while deeper unknowns become specific upgrade paths instead of exaggerated findings.
What the public response can establish
Suppose the submitted URL returns no Content-Security-Policy header. The response itself is deterministic evidence, so the result can be Confirmed. The report should still avoid claiming that an injection vulnerability exists: CSP is a browser control that can reduce the impact of some injection paths, not proof that such a path is present.
You can inspect the headers for an app you own with:
curl -sS -D - -o /dev/null https://example.app/MDN documents how CSP controls which resources a browser may load and recommends report-only deployment as a way to test a policy before enforcement. See MDN’s Content Security Policy guide.
Other public observations include:
- a referenced source map that returns source content;
- a development build or verbose public error;
- a token-like value embedded in a referenced bundle;
- framework, host, and API-route strings present in public code;
- cookie attributes and browser storage visible during normal page load.
The scanner may map a discovered route name, but it does not call that route to see what comes back. Observation and exploration are different activities.
Public does not always mean secret leak
Build tooling intentionally exposes some configuration. Vite replaces variables prefixed with VITE_ into client-side code and warns that sensitive values should not use that prefix. A variable name is therefore not enough to classify the value; the provider and key role matter.
Primary reference: Vite — Env Variables and Modes.
Supabase makes the distinction explicit. Publishable keys are designed for public components such as web pages. A service-role or secret key belongs on the backend. Finding a Supabase project URL and publishable key in JavaScript is usually Informational, not a credential leak.
Primary reference: Supabase — Understanding API keys. The SafeForProd guide to Supabase publishable versus service-role keys shows how that distinction changes a scan result.
What remains unknown after the free scan
| Question | Free-scan result | Access needed |
|---|---|---|
| Is the submitted page missing CSP? | Can be Confirmed from its response | Live URL |
| Is a publishable Supabase key visible? | Informational context | Public bundle |
| Does every table enforce the intended RLS policy? | Not tested | Source/policy access and approved role validation |
| Does an API reject the wrong user? | Not tested; route may only be mapped | Verified domain, approved account, bounded request |
| Can one tenant read another tenant’s data? | Not tested | Source review and explicit multi-role test scope |
| Does checkout trust a client-supplied price? | Usually not observable | Source or Human security review |
Supabase says RLS should be enabled on exposed-schema tables and describes policies as rules applied whenever a table is accessed. Confirming whether those rules match the app’s intended users requires policy or approved runtime evidence; a project URL alone cannot answer it. See Supabase — Row Level Security.
Why the limitation creates the upgrade
The free scan is not a smaller version of every possible security test. It is the “see” layer: a fast, evidence-backed view of the deployed public surface. It earns attention by finding concrete exposure without asking for an account or source code.
The planned Authorized source scan is the “reach” layer. After account creation, source submission, explicit authorization, and domain verification, it can compare routes, auth checks, RLS policies, dependencies, and deployment behavior. Bounded runtime checks can then answer some of the questions the free report deliberately leaves open.
The Human security review is the “reason” layer. It is for business logic, architecture, sensitive workflows, and prioritization that require context rather than pattern matching.
This is the upsell in plain language: the free scan finds the public signal; deeper access determines whether the signal leads to a real server-side failure.
Limitations
The examples above explain test boundaries; they are not prevalence statistics or results from a SafeForProd customer dataset. The free scan also sees only the submitted page and what that page references during normal loading. It does not prove that every route on the same domain has the same headers or public assets.