Supabase service_role key leaked? It bypasses RLS — act now

1. Step 01

   Open the Supabase project → Settings → API. Click "Reset service_role key". The old key dies instantly.

2. Step 02

   Update the new key in your server env vars only. It must never reach the browser.

3. Step 03

   Audit your auth.users, public schema, and storage buckets for unfamiliar rows or files.

Step 01 — Revoke

Kill the leaked credential first

Settings → API → "service_role" row → "Reset" button. Confirm with your password. Copy the new key once. Then update SUPABASE_SERVICE_ROLE_KEY in Vercel/Railway/etc. — never on the client.

Step 02 — Rotate

Update the new key in the right place

Server-side env vars only — never in client code, never with NEXT_PUBLIC_.

import { createClient } from '@supabase/supabase-js';
// SERVER ONLY. Use only inside Route Handlers, Server Actions, or cron jobs.
export const supabaseAdmin = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!,  // NOT NEXT_PUBLIC_
  { auth: { persistSession: false } },
);

Step 03 — Scan

Confirm nothing else leaked alongside it

Scan to confirm no other service-role JWTs are floating in your bundle, and that RLS is enabled on every public table.

How this usually leaks

• 01Used in a client component because the developer was confused between anon and service_role.
• 02Pasted into NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY — exposed to every page view.
• 03.env file pushed to GitHub on first deploy.
• 04Logged to a public server log endpoint.