How a scan works

LeakSweep runs an automated check. It is not a penetration test, a certification, or a guarantee that an app is secure. A clear report does not mean there is nothing else wrong.

Authorisation first

I am the owner of this application, or I have explicit permission from the owner to test it. I authorise LeakSweep to make passive, non-destructive requests to this site and to APIs it publicly references. I understand that accessing a computer system without authorisation is an offence under the Computer Misuse Act 1990.

The server stores that tick. It still will not fetch the site until a token matches either a DNS TXT record or a file at /.well-known/leaksweep-verify.txt. Monitoring re-checks the token before every weekly run. If it is gone, nothing is scanned.

What a Quick Scan requests

• The homepage, and same-site script files linked from it, with GET.
• A short list of sensitive paths such as /.env and /.git/config. A catch-all HTML page is ignored.
• One request with a made-up Origin header, to see whether CORS copies it.
• A TLS handshake, to read the certificate and protocol. No application data is sent.

What a Deep Scan adds

• If the JavaScript contains a Supabase URL and an anon or publishable key, a HEAD request asks for a row count. The body is discarded.
• A POST sends a column name that does not exist. The point is to see an authorisation error rather than a missing-column error. A valid row is never sent. The service_role key is never used.
• Firebase checks use an aggregation count or a shallow Realtime Database response. Document fields and key names are discarded.
• If package.json or a lockfile is public, exact versions are sent to OSV. The advisory id is stored, not your source.

What we do not do

• No password guessing, no injection payloads, no exploit kits.
• No requests to private IP addresses, link-local addresses, or cloud metadata addresses.
• No storing of row data, document bodies, or full secret values.
• No scan of a domain that has not just proved ownership.