Redaxa · Privacy, before AI

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 asAPI key or token
CategoryCredentials and secrets
Severitycritical: direct account or system compromise, as with keys, passwords and tokens
Replaced with[SECRET]
Where it runsThe 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 rulescanner.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 asAPI key or token
Severitycritical: direct account or system compromise, as with keys, passwords and tokens
Replaced with[SECRET]
Probable serviceSupabase
Credential typeSecret API key (elevated access)
EvidenceSupabase-specific prefix. Secret keys can bypass Row Level Security; project and validity are not verified.
Recommended actionRevoke or rotate if genuine

Example 2

You paste

SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6InJlZGF4YWRvY3NzYW1wbGUiLCJyb2xlIjoic2VydmljZV9yb2xlIn0.RedaxaDocsSampleSignatureNotRealRedaxaDocsS

Redaxa returns

SUPABASE_SERVICE_ROLE_KEY=[SECRET]
Reported asAPI key or token
Severitycritical: direct account or system compromise, as with keys, passwords and tokens
Replaced with[SECRET]
Probable serviceSupabase (claimed issuer)
Credential typeJWT with privileged-role claim
EvidenceDecoded JWT claims are unverified. Neither the issuer, signature, owner nor expiry is authenticated by this check.
Recommended actionRevoke 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:

Values are always shown masked in repository reports. No key is ever tested against its provider.

What it does not flag

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 check

Worried it is already in your code? Check a public GitHub repository free (3 checks a day).

Related

Sources