Supabase service_role Key Leaked? Fix It in This Order

1. Rotate first

In the Supabase dashboard, rotate the exposed key (API keys settings; for legacy JWT keys this means rotating the JWT secret, which also invalidates the anon key and existing sessions). Update every server that legitimately uses it.

Rotation comes before code cleanup because the old key is already public.

2. Remove it from client code

Create the browser client with the anon/publishable key only. Move anything that genuinely needs elevated access into an Edge Function or server route that checks the caller's identity first.

// browser
export const supabase = createClient(url, process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!);

// server only
const admin = createClient(url, process.env.SUPABASE_SERVICE_ROLE_KEY!, { auth: { persistSession: false } });

3. Review what may have been accessed

Check Supabase logs (API and Postgres) for unusual request volume or IPs during the exposure window, look for unexpected rows, users, or storage objects, and consider whether you need to notify users under your privacy obligations.

Checklist

• Key rotated
• Client uses anon/publishable key only
• Privileged logic in server code with auth checks
• Logs reviewed for the exposure window
• Build output re-scanned

Copy-paste fix prompt

My Supabase service_role key is in client code. Remove every client-side reference, recreate the browser client with the anon key, move admin operations into a Supabase Edge Function that verifies the caller's JWT, and list the places I must update after rotating the key.

FAQ