This week a scheduled scan surfaced a Replit app with three provider API keys in its public JS bundle. Sharing the walkthrough because the failure pattern is becoming common.
The finding
Scanner batch, 150 targets, diverse mix. One hit:
- Target: an anonymous Replit-hosted agency-dashboard app
- Bundle path:
/assets/index-Bcsl4CB1.js(standard Vite build output) - Bundle size: 1.2 MB
Three keys embedded directly in the JS:
- Anthropic:
sk-ant-api03-JsF-oz55AG5IDi...(full 88-character key, valid format) - OpenAI:
sk-proj-jVa3R7pY_ZYLFfjVfP6GLf8bx...(full project key) - Google: two
AIzaSy...keys (likely Places/Maps)
Plus a literal "password":"text" field in a JSON config.
How the scanner caught it
Our secret-scan module fetches the app's homepage, extracts <script src="..."> references (up to 3), downloads each bundle (up to 5 MB), and runs ~38 provider-specific regexes against the combined corpus. The Anthropic pattern is sk-ant-api\d+-[0-9A-Za-z_\-]{80,}. When it matches, severity is CRITICAL automatically.
The bundle also happened to be Vite-minified, so the keys weren't even wrapped in a function call — they were literal top-level constants. The entire scan took 4 seconds.
Why it's bad
Anyone visiting the app — or running curl $HOMEPAGE | grep sk- — gets working credentials. Anthropic rate limits are per-account, not per-deployment, so the account owner's quota is shared with everyone who notices. If the account has credits on file, the key pays for those credits.
OpenAI project keys are typically scoped with a budget cap, but if the cap is higher than zero, it's a money-drain.
Google API keys with AIzaSy... format are usually for Maps/Places/Geocoding. If they're usage-capped, the damage is bounded; if not, they can accrue bills fast.
What we did
The app was anonymous — no contact info, no real "about us" (their team page had template-placeholder names), no Twitter handle, no footer. There was no way to reach the owner directly without going through Replit.
So we did the next-best thing: we notified Anthropic and OpenAI's security teams with the full key value and the source URL. Both providers have internal tooling to match a leaked key back to the customer account and revoke it server-side. The customer gets a rotation notice from the provider ("your key was rotated due to leak detection") and fixes their app.
The key was revoked within a few hours of our email. Total elapsed time from scanner detection to revocation: about 90 minutes.
How to not be that app
- Never call AI providers from the client. Not even "just for the demo." Not even with a "billing cap." Put the call behind your own
/api/ai-chatendpoint, read the key fromprocess.env, and require user auth. - Bundle-scan your own app before deploy. A regex check in your CI for
sk-ant-,sk-proj-,sk_live_,AIzaSy,AKIA, andeyJ...service_rolecatches 90% of this class of leak. - If you've already shipped a key, rotate it. Rotating in the provider dashboard takes 10 seconds. The old key is dead instantly.
We kept the scanner's secret-regex list up to date as providers add new prefix formats. If you know of a format we're missing, email us at [email protected].