Secret & API Key Leak Scanner
Paste code, an .env file, or logs. We flag leaked Supabase service-role keys, provider tokens, and database URLs, and we tell a public anon key apart from a dangerous one. Nothing leaves your browser.
Find leaked API keys and secrets before you commit
Secrets end up in the wrong place all the time. A key gets pasted into a component to test something and never removed. A connection string lands in a log line. A .env file gets committed by accident. This scanner is a fast way to check a chunk of code, a config file, or a log before it goes somewhere public. Paste the text and it highlights anything that looks like a credential, with a severity and a short note on what to do about it.
The part that matters most for Supabase projects is telling one key from another. The anon key and the service_role key are both JWTs and look nearly the same at a glance, but one is safe to publish and the other bypasses Row-Level Security entirely. The scanner decodes the token, reads the role claim, and marks a leaked service-role key as critical while treating an anon key as public by design.
What it looks for
- Supabase service-role keys, which are critical if they ever leave your server.
- Supabase anon keys, flagged for awareness rather than alarm.
- Database connection URLs like
postgres://user:password@host/db, which carry a password in plain sight. - Provider API keys, including OpenAI, OpenRouter, and Resend.
- Webhook signing secrets and GitHub tokens.
- Raw symmetric keys and bcrypt hashes that should not be sitting in source.
Why keys leak in the first place
The root cause is almost always the same: a secret that needs to stay on the server ends up in code that ships to the browser. Client-side apps make this easy to do by accident, because there is no hard line between what runs on your machine and what runs on a stranger's. Once a service-role key is in a bundle or a public repo, it is compromised, and the only real fix is to rotate it.
The durable fix
Scanning catches a leak after it happens. The way to stop leaks is to never put the secret in the browser at all. Suparbase proxies every Supabase request through an authenticated server-side route, so your service-role key is encrypted at rest and used only on the server. The browser holds a session cookie and nothing else. Your keys stay where they belong.
Frequently asked questions
- Does my code get uploaded when I scan it?
- No. The scan runs entirely in your browser using pattern matching in JavaScript. Nothing you paste is sent to a server, logged, or stored. You can disconnect from the internet after the page loads and it still works.
- What is the difference between an anon key and a service-role key?
- Both are JWTs, so they look almost identical. The difference is a single claim inside them. The anon key has role set to anon and is meant to be public. The service-role key has role set to service_role, bypasses Row-Level Security, and must stay on your server. The scanner decodes the token and reads that claim, so it can tell you which one you pasted and flag the dangerous one.
- Is it a problem if my anon key shows up in my code?
- Usually not. The anon key is designed to ship in your client bundle, so finding it in frontend code is expected. It is only a risk if your tables lack Row-Level Security, because then the public key can read data it should not. If that worries you, run the Security Scanner to check your tables.
- What kinds of secrets does it detect?
- Supabase service-role and anon JWTs, Postgres and other database connection URLs with embedded passwords, provider API keys such as OpenAI and OpenRouter, Resend keys, Stripe and webhook signing secrets, GitHub tokens, bcrypt hashes, and raw symmetric keys that look like encryption or HMAC material.
- It flagged a string that is not actually a secret. Why?
- Pattern matching is careful but not perfect. A long random-looking string can match the shape of a key even when it is not one. Treat the results as a prompt to look, not a verdict. The severity and the type label help you judge quickly whether each hit is real.
Keys leak because they reach the browser.
Suparbase proxies every Supabase request server-side, so your service-role key stays encrypted at rest and never ships to a client.