Service Role Key Exposure

What Is This Vulnerability

The Supabase service_role key is a privileged API key that bypasses all Row Level Security policies and has full read/write access to every table, storage bucket, and auth system in your project. It is intended exclusively for server-side use in trusted environments like Edge Functions, backend servers, or CI/CD pipelines.

When this key is exposed in client-side code (JavaScript bundles, mobile apps, or browser-accessible configuration), any user can extract it and gain unrestricted access to your entire database. Unlike the anon key, which respects RLS, the service_role key operates with superuser-like privileges.

// CRITICAL VULNERABILITY: service_role key in client-side code
const supabase = createClient(
  'https://abc.supabase.co',
  'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyb2xlIjoic2VydmljZV9yb2xlIn0...'
  //    ^^^ This is a service_role key - NEVER use client-side
);

Why It's Dangerous

A leaked service_role key gives an attacker complete control over your Supabase project:

• Bypass all RLS: Read, insert, update, and delete any row in any table regardless of policies
• Access auth.users: Read all user emails, passwords hashes, metadata, and session tokens
• Impersonate users: Generate auth tokens for any user, taking over their accounts
• Delete all data: Truncate tables, drop data, or corrupt the entire database
• Access storage: Read, write, and delete files in all storage buckets
• Modify schema: Execute arbitrary SQL if the key is used with the management API
• Exfiltrate everything: Dump the complete database including all user data

This is equivalent to giving the attacker your database root password. It is the most severe vulnerability possible in a Supabase application.

# With the service_role key, an attacker can read ALL data
curl 'https://YOUR_PROJECT.supabase.co/rest/v1/user_profiles?select=*' \
  -H "apikey: SERVICE_ROLE_KEY" \
  -H "Authorization: Bearer SERVICE_ROLE_KEY"
# RLS is completely bypassed - returns every row

How to Detect

Search your client-side code for the service_role key:

# Search for service_role JWT pattern in your codebase
grep -r "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyb2xlIjoic2VydmljZV9yb2xl" ./src/
grep -r "service_role" ./src/ --include="*.ts" --include="*.js" --include="*.tsx"
grep -r "SUPABASE_SERVICE_ROLE" ./src/ --include="*.ts" --include="*.js"

Check your bundled JavaScript in the browser DevTools Network tab or Sources panel. Search for JWT tokens and decode them at jwt.io. If the payload contains "role": "service_role", the key is exposed.

AuditYourApp scans client-side JavaScript bundles and network requests for service_role key patterns and immediately flags any exposure as critical.

How to Fix

Immediately rotate the key if it has been exposed:

1. Go to Supabase Dashboard > Settings > API
2. Generate a new service_role key (this invalidates the old one)
3. Update all server-side code with the new key
4. Audit your database for any unauthorized changes made while the key was exposed

Ensure the service_role key is only used in server-side environments:

// CORRECT: service_role key in an Edge Function (server-side only)
const supabaseAdmin = createClient(
  Deno.env.get('SUPABASE_URL')!,
  Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
);

// CORRECT: Client-side code uses only the anon key
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
);

Never prefix environment variables containing the service_role key with NEXT_PUBLIC_, VITE_, REACT_APP_, or any client-exposed prefix. Store it exclusively in server-side environment variables or secret managers. Add the key pattern to your .gitignore and use pre-commit hooks to prevent accidental commits containing the key.