Secrets and API keys exposed in the frontend
Everything in your frontend JavaScript is public. When an AI builder puts a secret key in the browser code, a Stripe secret key, a service role key, an OpenAI or AWS key, anyone can open the bundle and copy it. Some keys are meant to be public; the dangerous ones are the private ones that end up there by mistake.
What it looks like
A secret that belongs on the server ends up in the code that ships to the browser: hard-coded in a component, baked into the build, or left in a source map. It works, so nobody notices, until someone reads it.
Why it matters
A leaked private key is a leaked account. A Stripe secret key can move money. A cloud key can spin up resources on your bill. A Supabase service role key bypasses all of your Row Level Security and reads everything. This is one of the fastest paths from an app to a serious incident.
How ArgosX detects it
ArgosX scans your shipped JavaScript and source maps for key shapes and secret-named fields, and grades them by how dangerous the key actually is. Publishable keys that are meant to be public are noted but not alarmed; private keys are flagged high.
How to fix it
Move every private secret to the server and rotate anything that has already shipped.
- Keep secret keys in server-side environment variables or edge functions, never in client code.
- Rotate any key that was ever in your frontend. Assume it is already copied.
- Use the publishable or anon variant of a key in the browser, and pair it with proper access rules.
Check your own app for this, free.
A free scan runs in minutes, no signup. Where it finds this, it proves it with the request and screenshot, not just a maybe. A human-verified pass is available when you want a person to confirm every finding.