Secret Leak Scanner

Leaked keys are a frequent problem in projects that changed hands or were built quickly with AI tools. A key pasted into a config file, committed to git or bundled into front-end code can be found and misused long after everyone has forgotten about it. This scanner checks text you paste, such as source files, .env files or config, and points out values that look like credentials. It runs 100% in your browser. Nothing you paste is uploaded.

What it looks for

The scanner combines known key patterns with an entropy check that spots long, random-looking strings. It recognises, among others:

• Cloud keys: AWS access key IDs (starting AKIA or ASIA) and nearby secret access keys.
• Payment keys: Stripe secret keys (sk_live_, sk_test_) and restricted keys (rk_).
• Code hosting tokens: GitHub tokens such as ghp_, gho_, ghs_ and fine-grained github_pat_ tokens.
• Google API keys starting with AIza.
• Slack bot and user tokens (xoxb-, xoxp-) and incoming webhook URLs.
• AI provider keys in the OpenAI style (sk-, sk-proj-).
• Supabase service-role keys, which are JWTs whose payload carries the service_role role, and newer secret keys.
• Private keys in PEM blocks such as -----BEGIN RSA PRIVATE KEY----- or -----BEGIN OPENSSH PRIVATE KEY-----.
• Database connection URLs with a password inside, for example postgres://user:password@host/db.
• JWT signing secrets and other variables whose names suggest a secret, such as JWT_SECRET or SESSION_SECRET.

How to read the results

Each hit shows the line, the type of credential the scanner thinks it is, and how confident it is. Sort them in this order:

1. Live secrets such as live payment keys, service-role keys, private keys and database URLs. Act on these today.
2. Test or development keys. Less urgent, but test accounts can still leak customer-like data or run up costs, so rotate them too.
3. Public-by-design keys such as Stripe publishable keys, Supabase anon or publishable keys, and Firebase web config values. These are fine in the browser, but only if your backend rules are correct. Use the Supabase RLS Checker to review those rules.
4. Entropy-only hits. Random-looking strings with no known format. Check them by hand; many are hashes or IDs.

One rule overrides everything else: anything shipped to the browser is public. If a secret sits in a variable prefixed VITE_, NEXT_PUBLIC_ or similar, it is in your front-end bundle and anyone can read it, even if it never touched git.

What to do when you find a real secret

1. Rotate or revoke the key first. Create a new key in the provider's dashboard, update your app, then revoke the old one. This is the step that actually stops misuse.
2. Check for misuse. Look at the provider's logs, billing and usage pages for activity you do not recognise.
3. Move the value out of code. Store it in your host's environment variables or a secrets manager, and read it at runtime on the server.
4. Remove it from git history. On a fresh clone, use git filter-repo or BFG, then force-push and ask collaborators to re-clone.

# git filter-repo: remove a file from every commit
git filter-repo --invert-paths --path .env

# BFG: replace listed secret strings across history
bfg --replace-text secrets-to-remove.txt
git reflog expire --expire=now --all && git gc --prune=now --aggressive

Forks, clones and cached copies can keep the old history, which is why rotation always comes before clean-up.

5. Prevent the next one. Add .env files to .gitignore, commit a .env.example with names only, and turn on secret scanning or push protection in your git host if it offers it.

During a handover

Scan before you give a new developer access, so you know what they will see. After the handover, rotate every credential the previous developer could reach, even if nothing leaked. Our guides on giving a developer access without sharing passwords and securing your accounts when a developer disappears walk through both steps. If your app was built with an AI builder, the vibe-coded prototype to production checklist covers the wider clean-up.

Limitations

• The scanner only sees the text you paste. It cannot read your repository history, your hosting dashboard or your built bundle.
• Pattern matching misses custom or unusual formats, and entropy checks raise false alarms.
• It does not test whether a key still works. Assume any real-looking key is live until you have revoked it.

Results are guidance, not a security audit.

Found more than you can handle?

If the scan shows keys spread across the codebase, or you are not sure which ones the app still uses, read about security issues in AI-generated apps. If you want a developer to clean it up properly, post your takeover for free. Describe what you found, but never paste the keys themselves into the listing.