Exposed Supabase key? What to do now (anon vs service role)

You found your Supabase key in your app's JavaScript, a GitHub repo or a screenshot. Before you panic, work out which key it is. What you do next depends entirely on that.

Step 1: Identify the key

Key	Where you see it	Is it meant to be public?
anon key or publishable key (sb_publishable_...)	Project Settings, API Keys	Yes. It is designed to ship in the browser.
service_role key or secret key (sb_secret_...)	Project Settings, API Keys	No. It bypasses Row Level Security.

Legacy keys are long JWTs; you can tell them apart by the role claim inside (anon or service_role). Newer keys use the sb_publishable_ and sb_secret_ formats, and Supabase is deprecating the legacy anon and service_role keys by the end of 2026 (Supabase API keys). More detail: Supabase anon key vs service role key.

If it is the anon or publishable key

This key being visible is normal. The real question is whether your database rules hold:

1. Confirm RLS is enabled on every table in the exposed schemas.
2. Read each policy. Remove any using (true) policy that is not intentional. See permissive RLS policies.
3. Check storage buckets and RPC functions too. See storage bucket security and security definer functions.
4. Clear the Security Advisor warnings.

If it is the service role or secret key

Treat it as an emergency. Anyone with this key can read and write your whole database, ignoring RLS.

1. Rotate it first. In Settings, API Keys, create a new secret key (sb_secret_...), put it everywhere your backend used the old one, then delete the exposed key. If the leak was a legacy service_role JWT, Supabase's procedure is the same: replace it with a new secret key, then disable the legacy keys so the old JWT stops working (Supabase: rotate a leaked key).
2. Move the new key server side. It belongs only in server code, Edge Functions or your host's secret settings, never in a VITE_, NEXT_PUBLIC_ or other browser exposed variable. See environment variables in Cursor, Bolt and Lovable.
3. Look for misuse. Check your Supabase logs and recent data changes for activity you do not recognize. If rows were deleted, see recover deleted Supabase rows before you restore anything. If the key sat in a host's environment variables during a breach, such as Railway in October 2026, rotate the database password and other secrets too (what to rotate after the Railway breach).
4. Clean up after the key is dead. Remove it from code, then decide whether to rewrite git history. See remove an API key from GitHub history.
5. Stop it happening again. Add secret scanning before commits. See Gitleaks and push protection.

The general playbook is in the first hour after an API key leaks.

Check what is exposed right now

LeakCheck can check your live app for shipped secrets and open Supabase data with read only requests, and check a public GitHub repo for leaked keys in your browser.

• LeakCheck Free: one preview scan with no account: score, grade, and every finding by title. Sign in free for more scans and full details plus a fix prompt for the top 2.
• LeakCheck Pro: $15 USD a month or $144 USD a year (CA$20 a month or CA$192 a year in Canada). Every finding in full, up to 5 watched apps, a rescan seconds after every deploy and alerts by email, Slack or Discord if a key or open table comes back.

Check yours now

Make sure nothing else is exposed. Run a free LeakCheck scan on your app and repo. Then let LeakCheck Pro recheck after every deploy.