Check a public site for leaked keys

Last edited 2026-10-31.

What it checks

The free scan reads the submitted page HTML and up to eight same-origin script URLs found in script tags or script preload links, with a 750,000-byte read cap per file and a ten-second request budget.Scan limits and script selection.

It looks for Supabase service-role tokens and secret keys, Stripe secret or restricted key patterns, Anthropic and OpenAI key patterns, and AWS access-key IDs, then reports only a short prefix.Detection rules and masking. Treat each match as a lead to investigate in your provider dashboard; avoid copying credentials into a support message.

The header check records whether Content-Security-Policy, Strict-Transport-Security and X-Frame-Options have nonempty values on the fetched page response.Header presence checks. Read the actual values in your browser's Network panel before deciding which configuration to change.

What it can't see

The free check does not sign in, execute JavaScript, traverse every route, inspect your private repository, or validate matched credentials with their provider.Free scan request flow. For a practical follow-up, inspect the routes you use after login, lazy-loaded assets, deployment settings and server logs separately. Start with the route where you recently changed an integration, then compare its production assets with the files from your latest build.

Script contents are capped independently, while the displayed truncation flag describes the page HTML; a script-size limit is not separately reported.Read caps and returned result fields. Do not interpret a short result as a complete review of a large application. Record the checked URL, script count and any timeout or skipped-script notice alongside your own follow-up notes.

How to read the result

1. A key pattern matched: compare the prefix privately with the relevant provider dashboard. For a confirmed exposure, revoke the credential, replace it in the correct server environment and remove it from public assets, following OWASP's remediation guidance. Then rebuild, redeploy and repeat the check on the published URL.
2. No pattern matched: continue the manual checks above; do not use the result as a security certificate. Review the implemented patterns before assuming a particular provider or token format is covered.
3. A header is missing: review the matching deployment setting and the intended policy. OWASP recommends CSP frame-ancestors where possible as a replacement for X-Frame-Options in supporting browsers, so an absent X-Frame-Options header alone is not a complete framing assessment.OWASP header guidance.
4. A header is present: inspect its policy rather than treating presence as a pass. Compare your values with OWASP's configuration recommendations, test the change on a preview deployment, and check that sign-in, embedded content and checkout still work.

Stripe publishable keys are intended for frontend use; restricted keys have configurable permissions and must remain secret.Stripe's key types. Check the key type and permissions before assessing impact, rather than assuming every key-shaped string grants the same access. For the next steps, use theStripe exposed-key guide or theSupabase service-role guide.

Check this site after each deployment you want to investigate.