Secret scanning
The secret scanner that also checks what already shipped
Prbl finds API keys, tokens, passwords and signing secrets hardcoded in your repository, and the keys sitting inside your deployed app's JavaScript that every visitor can read. It tells the difference between a real leak and a key that is public by design, and it fixes what it finds.
The most common serious flaw in AI-built apps
We scanned 2,148 repositories built with Cursor, Claude, Codex, Lovable and Bolt. In every group, the top high-severity finding was the same: a hardcoded credential, 276 repos in all, ahead of path traversal, code injection and everything else. Live, the pattern continues: keys in the page source, a service_role key in a bundle, an environment file served from the root.
It happens because the key pasted inline is the shortest path to a working feature, and the tools optimise for working. It keeps happening after “use environment variables” because the tool reaches for NEXT_PUBLIC_ or VITE_, which are the variables that ship to the browser. A secret scanner for this era has to know both of those things.
What it finds in your code
OpenAI, Stripe, AWS, GitHub, Google, Firecrawl, TMDB and any other provider key assigned to a variable or dropped in a config object
Database URLs with credentials inline, admin passwords in seed scripts, demo logins left in the auth page
JWT secrets, cookie secrets, webhook signing secrets, including the fallback pattern process.env.SECRET || 'dev-secret'
AES keys and IVs as string literals
.env files checked into the repo, and secrets that moved to NEXT_PUBLIC_ or VITE_ variables and therefore ship to the browser
Rules PRBL-C001 and PRBL-C002, with test fixtures, placeholders and public-by-design values excluded after manual review of real repos.
What it finds in your live app
Paste a URL instead of a repo. Prbl loads the page and its scripts the way a browser does, then looks for the keys that should never have made it to the client.
Stripe sk_live_, AWS access keys, OpenAI, GitHub tokens and private keys found in the page and up to a dozen loaded scripts
The anon key (public by design, flagged so you verify row level security) and the service_role key (never public, high severity)
Firebase config blocks and AIza keys, flagged at medium so you check restrictions rather than panic
/.env, /.env.local, /.env.production and /.git/config being served by the host
Read-only. Secrets are redacted in the findings and nothing is stored. Related free tools: exposed .env checker · Supabase RLS checker.
What happens after the finding
Which key, where, why it matters, and whether it is a real leak or a public-by-design key that needs a configuration check.
A paste-ready prompt for Cursor or Claude that moves the secret to a server-side environment variable and updates every reference.
The rewriter applies the change, runs the app against a behavioral baseline to prove nothing broke, and re-scans to confirm the secret is gone.
Then it keeps watching. The free GitHub Action scans every pull request and comments the finding before the key merges.
Prbl vs dedicated secret scanners
GitGuardian, gitleaks and TruffleHog are the reference tools for scanning git history. Here is where Prbl overlaps and where it does not.
| Prbl | History scanners | |
|---|---|---|
| Scans | Source code plus the deployed app's JavaScript and exposed files | Git history and source, sometimes CI logs |
| Provider coverage | The providers AI-built apps actually use, tuned on real repos | Hundreds of detectors across every provider |
| Git history | Current tree; history is on you (guide linked below) | Yes, full history, the core feature |
| Public-by-design keys | Classified: Supabase anon and Firebase config are medium with a verify step, not false alarms | Often flagged as secrets, or ignored entirely |
| After the finding | A fix prompt per finding; the rewriter moves the secret to an env var and verifies | An alert; rotation and cleanup are on you |
| Beyond secrets | Missing auth, injection, path traversal, open databases in the same scan | Secrets only, or a separate product |
| Cost to start | Free, no account | Free CLI tools exist; platforms are per-seat |
Head to head: Prbl vs GitGuardian. If a key was ever committed, also read how to remove a secret from git history.
Frequently asked questions
What is a secret scanner?
A secret scanner reads code, config, and sometimes git history or deployed assets looking for credentials that should never be there: API keys, tokens, passwords, private keys, signing secrets. Prbl's secret scanner does this in two places: the repository, where it catches the key before it ships, and the live app, where it catches the key that already shipped inside the JavaScript everyone downloads.
How is this different from GitGuardian, gitleaks or TruffleHog?
Those are excellent at one job: scanning git history for anything that looks like a secret, across hundreds of providers. Prbl scans the current code and the deployed app, classifies keys that are public by design so you are not chasing false alarms, and fixes the finding rather than just reporting it. If you need history scanning, run gitleaks too; it is free. If you want the secret found, explained and moved to an environment variable, that is Prbl.
Why does AI-generated code have so many hardcoded secrets?
Because the fastest way to make a feature work is to paste the key inline, and AI tools optimise for the feature working. Across the 2,148 AI-built repositories we scanned, a hardcoded credential was the most common high-severity finding in every single group, affecting 276 repos. The tools also tend to move a secret into a NEXT_PUBLIC_ or VITE_ variable when asked to use environment variables, which silently ships it to the browser.
Is a Supabase anon key or Firebase API key a leaked secret?
No, and a good scanner should not treat it as one. Both are designed to be public. They are only dangerous when the thing behind them is misconfigured: Supabase row level security off, or Firebase rules open. Prbl flags them at medium severity with a verification step, and can actively test whether the database is readable, instead of either crying wolf or ignoring them.
I found a secret. What do I do?
Rotate it first, before cleaning up, because assume it has been read. Then move it to an environment variable that is not prefixed for the browser, remove it from the code, and if it was ever committed, rewrite the git history or accept that the old value is public forever (rotation covers that). Every Prbl finding includes the specific fix for the pattern it found.
Does the scanner store my code or the secrets it finds?
No. Repos are cloned, scanned and deleted; findings record file, line and rule only. Secrets found in live apps are redacted in the output. Details are on the trust page.
Find out in a minute whether a key is sitting in your code or your deployed app. Public repo or live URL, no account.
Scan for secrets →Guides: find hardcoded secrets in a codebase · stop AI tools hardcoding secrets · what happens when you push a key to a public repo · the NEXT_PUBLIC leak · hardcoded JWT secret fix · SAST for AI code