DEV Community: ShipSafeStack

Is the Supabase anon key safe to expose?

ShipSafeStack — Fri, 06 Nov 2026 15:10:01 +0000

Practical checklist from ShipSafeStack. Not a penetration test, compliance audit, score, or proof that a project is safe. Informational only — no guarantees.

Short answer: Supabase’s docs say the anon key, and the newer publishable key, are meant to be in the browser. They are not a secret. That only holds when row level security is on and the grants are tight. The service_role key and the newer secret key (sb_secret_…) bypass RLS and do not belong in the client.

If RLS is off, or grants are wide open, the anon key is a public handle on a public table. Setup steps: how to set up Supabase RLS for an AI-built app. After policies exist: RLS checklist.

Which key is which

Supabase’s API key docs describe four keys — two for code you ship, two that are elevated:

Key	Format	What Supabase says
Publishable key	`sb_publishable_…`	Low privilege. OK in a web page or mobile app. Only reaches what RLS allows.
Anon key	Long JWT	Legacy publishable key. Same idea: identifies the project; not a secret.
Secret key	`sb_secret_…`	Elevated. Bypasses RLS. Server / Edge Function / backend you control.
Service role key	Long JWT	Legacy secret key. Same bypass. Prefer a secret key where you can.

A publishable key with no signed-in user acts as the anon Postgres role. With a signed-in user it acts as authenticated. A secret/service_role key bypasses RLS — policies for anon / authenticated do not apply to it.

Creating a publishable or secret key does not revoke the legacy keys until you disable them under Settings → API Keys.

How to tell an anon JWT from a service_role JWT

Both legacy keys are JWTs, so both can start with eyJ. The prefix is not the difference — the payload is.

A JWT is three base64url segments. The middle segment is the payload (encoded, not encrypted). Decode that segment on your own machine and read the role field:

role of anon → anon key (expected in the client when RLS is correct)
role of service_role → service role key (never in the client, VITE_ / NEXT_PUBLIC_, or a public repo)
sb_publishable_… → newer public key; sb_secret_… → newer secret key

Do not paste live keys into a random website to decode them.

ShipSafeStack’s free passive check reports an anon JWT in public scripts as information; it does not treat that alone as a failure. A service_role JWT in public scripts is a different problem.

When the anon key is the wrong thing to worry about

Worry first about:

RLS disabled or missing on tables the client can reach
Policies that only check “signed in” without scoping rows to that user
Default grants that are wider than your policies
A service role / secret key that also shipped in the browser, repo, or chat

If the service role key leaked

Treat it as compromised. Remove it from the client first, put a new secret only on the server, rotate at Supabase, and review logs/data. Full steps: Supabase service role key exposed: what to do now.

FAQ (condensed)

Can the anon key sit in a public GitHub repo? Supabase treats it as non-secret; the risk is still your RLS and grants, plus accidentally committing the service role beside it.
Both eyJ keys shipped? Decode payloads locally; rotate and remove the service_role one immediately; keep anon only if RLS is correct.
Does enabling RLS protect tables the service role reads? No — service role bypasses RLS.
Lovable / Bolt: public Supabase URL + anon/publishable values often go in client env (VITE_…); service role belongs in server Secrets / Edge Functions, not in the bundle.

Check a public URL (passive, free): shipsafestack.com/scan — ordinary GETs only; nothing stored; informational only, not an audit.

Original: Is the Supabase anon key safe to expose?

Pre-launch security checklist for vibe-coded apps

ShipSafeStack — Thu, 05 Nov 2026 15:20:41 +0000

Pre-launch security checklist for vibe-coded apps

Practical checklist from ShipSafeStack. Not a penetration test, compliance audit, score, or proof that an app is safe to launch. Informational only — no guarantees.

Run this on the project you are about to share. AI tools often repeat the same shortcuts: a key in the client, a table with no access rule, a price decided in the browser.

Builders this list covers include Lovable, Bolt.new, Cursor, v0, and Replit. Shorter per-builder lists live under Ship guides.

Before anyone else has the URL

Decide which URL is production and which URLs are previews. Preview links are often public. Treat a preview that has real data as production.
Read the environment variable list in the host dashboard. Anything the framework ships to the browser is public (for example VITE_ on Lovable, NEXT_PUBLIC_ on Next.js).
Search the repo and the built JavaScript for shapes like sk_live, service_role, sb_secret_, sk-, AKIA, and private key blocks. If you find a real secret, rotate it at the vendor, then remove it. Rotating without removing it leaks the next one.
Confirm the app is served over HTTPS and that you are not shipping a debug page, a stack trace, or a seed script with a known password.

What the model tends to ship

These are patterns vendors document — not a statistic about how often they appear.

A key next to a fetch in the client → confirm it is a publishable value, or move it to a server secret.
A new table with no access policy → row level security (or equivalent rules) exists, and a second user fails to read the first user’s rows.
A rule that only checks “is signed in” → the rule also checks which rows that person owns.
A price, plan, or “paid” flag set in the browser → the server records the result from the payment provider’s signed event, not from the success page.
An admin or service credential in client code → that credential lives only in a server function.

Secrets the browser can see

Sort publishable keys from secrets. Publishable (when the vendor says so): Stripe pk_, Supabase anon/publishable with RLS on, public analytics IDs.
Never ship in the client: Stripe sk_, Supabase service_role / sb_secret_, model keys, email provider keys, database URLs with passwords, webhook signing secrets.
Search the deployed site’s JavaScript (network panel → .js responses), not only the source tree.
Check host env screens: a client-prefixed variable is public even if the dashboard looks private.

More detail: API keys leaking into the frontend and How to keep API keys out of AI-generated code.

Data access

For Supabase: enable RLS, fix default grants, and add per-user policies before a client with the anon key talks to the database. See Supabase RLS for an AI-built app and the RLS checklist.
Prove a second account cannot read the first account’s rows.
The anon key in the browser is expected when RLS is correct; a service_role key in the browser is not. See Is the Supabase anon key safe to expose?.

Accounts, money, email, abuse

Confirm sessions are checked on the server for protected routes.
Record payments from the provider’s signed webhook, not from a browser “success” page — Stripe webhook verification checklist.
Keep email/API secrets on the server.
Put rate limits on public forms and auth routes on the server, not only by disabling a button — Rate limiting checklist.

After you have read the code

Re-check the production URL after deploy (headers, HTTPS, no debug pages).
Rotate anything that appeared in chat transcripts, screenshots, or old preview deployments.
If a Supabase service role key leaked: what to do now. If a GitHub token leaked: next 15 minutes.

Soft reminder

A green scan from a builder is not the same as finishing this list. Builder scans help; they are not a substitute for checking secrets, RLS, payments, and abuse controls yourself.

Check a public URL (passive, free): shipsafestack.com/scan — ordinary GETs only; nothing stored; informational only, not an audit.

Original: Pre-launch security checklist for vibe-coded apps