Detection reference · Credentials and secrets · Updated 2026-11-03
Supabase keys: secret, publishable, anon and service_role
Supabase ships one key that is meant to be public and one that bypasses Row Level Security. Mixing them up in a prompt or a repository is a common mistake, so Redaxa reads the prefix and, for legacy JWT keys, the role claim.
At a glance
| Reported as | API key or token |
|---|---|
| Category | Credentials and secrets |
| Severity | critical: direct account or system compromise, as with keys, passwords and tokens |
| Replaced with | [SECRET] |
| Where it runs | The same engine runs in the Chrome extension (free checks, on your device), in the web check and the Windows app (on Redaxa's server; the text is not stored) and in public repository checks. |
| Engine rule | scanner.ts, line 205 |
What it looks like
New-style keys: sb_secret_ and sb_publishable_ followed by at least 20 characters. Legacy keys are JWTs: Redaxa decodes the payload (without verifying the signature) and looks at iss and role.
Example 1
You paste
SUPABASE_SECRET_KEY=sb_secret_RedaxaDocsSampleNotRealRedaxaDoc
Redaxa returns
SUPABASE_SECRET_KEY=[SECRET]
| Reported as | API key or token |
|---|---|
| Severity | critical: direct account or system compromise, as with keys, passwords and tokens |
| Replaced with | [SECRET] |
| Probable service | Supabase |
| Credential type | Secret API key (elevated access) |
| Evidence | Supabase-specific prefix. Secret keys can bypass Row Level Security; project and validity are not verified. |
| Recommended action | Revoke or rotate if genuine |
Example 2
You paste
SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6InJlZGF4YWRvY3NzYW1wbGUiLCJyb2xlIjoic2VydmljZV9yb2xlIn0.RedaxaDocsSampleSignatureNotRealRedaxaDocsS
Redaxa returns
SUPABASE_SERVICE_ROLE_KEY=[SECRET]
| Reported as | API key or token |
|---|---|
| Severity | critical: direct account or system compromise, as with keys, passwords and tokens |
| Replaced with | [SECRET] |
| Probable service | Supabase (claimed issuer) |
| Credential type | JWT with privileged-role claim |
| Evidence | Decoded JWT claims are unverified. Neither the issuer, signature, owner nor expiry is authenticated by this check. |
| Recommended action | Revoke or rotate if genuine |
All values on this page are synthetic or published specimens; none is a working credential or a real person's data.
In a repository check
The same example, committed to a public repository and run through the free repository check:
supabase/functions/admin.ts: API key or token, listed for review (severity critical). Credential pattern matched. Validity is not tested; review and rotate if genuine.- Same value in
tests/fixtures/admin.ts: Test or example value, counted but not listed. Real-looking keys in test files are still reported.
Values are always shown masked in repository reports. No key is ever tested against its provider.
What it does not flag
SUPABASE_PUBLISHABLE_KEY=sb_publishable_RedaxaDocsSampleNotRealRedaxaDoc: not flagged. A publishable key is a public client identifier; your database policies still decide what it can read.SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6InJlZGF4YWRvY3NzYW1wbGUiLCJyb2xlIjoiYW5vbiJ9.RedaxaDocsSampleSignatureNotRealRedaxaDocsS: not flagged. A JWT whose claims say role anon and a Supabase issuer is the public anon key. The signature is not verified.
If it already leaked
Rotate the secret key (or, for legacy keys, the JWT secret) in the Supabase dashboard's API key settings, then redeploy every server that used it. A leaked publishable or anon key needs no rotation, but it is a good moment to re-read your Row Level Security policies.
What Redaxa adds to every finding of this kind: If genuine, revoke or rotate it at the issuing service, update the application, then remove the exposed value from code and review Git history. Deleting it from Git does not revoke access.
What Redaxa adds to every finding of this kind: Identify the issuing application and whether this token grants access. If exposed and usable, invalidate the token or session using that service’s controls. Removing the token from a repository does not invalidate it.
Official guidance: supabase.com.
Step by step: pasted a key into ChatGPT, or committed one to GitHub.
Check before you paste
The free Chrome extension runs this check inside ChatGPT, Claude, Gemini and Perplexity before a message is sent, on your device and with no daily limit. On the web you get 5 free prompt checks a day with no account.
Add the Chrome extensionTry a free web checkWorried it is already in your code? Check a public GitHub repository free (3 checks a day).
Related
- GitHub tokens
- GitLab personal access tokens
- OpenAI API keys
- Anthropic API keys
- Stripe keys and webhook secrets
- Slack tokens and webhook URLs
- Google API keys
- AWS access keys
- npm access tokens
- PyPI API tokens
- Hugging Face access tokens
- SendGrid API keys
- JSON Web Tokens (JWT)
- Bearer tokens
- Passwords in URLs
- Secrets in configuration values
- Passwords written in text
- Private keys (PEM)
- I pasted an API key into ChatGPT: what to do
- Stop API keys leaking into AI prompts
- Check a public GitHub repository for leaked API keys
- Free GitHub secret scanner
- Everything Redaxa detects
Sources
- Redaxa engine: scanner.ts line 205, credential-context.ts line 34 (Supabase), credential-context.ts line 49 (Supabase (claimed issuer)). Every output on this page was produced by that code when the page was built.
- Supabase Docs: Understanding API keys