How to Find a Leaked Supabase Service Role Key

If your Supabase service_role key is leaked, an attacker can read, write, and delete all your database data, bypass Row Level Security, and access all auth users. This is the most dangerous key you can expose. Here's a step-by-step guide to find and fix a leaked Supabase service_role key before it's too late.

The Supabase service_role key is a secret token that grants full admin access to your Supabase project. Unlike the anon key, which is safe to expose in client-side code, the service_role key must never be shared publicly. If leaked, it can lead to total data loss, account takeover, and massive bills. In this guide, you'll learn how to scan your codebase, GitHub repos, and logs for a leaked supabase service role key, and how to rotate it immediately.

What Is a Supabase Service Role Key and Why Is It Dangerous?

The Supabase service_role key is used for server-side operations that need to bypass Row Level Security (RLS). It has unrestricted access to your database, storage, and auth APIs. If an attacker gets this key, they can:

A leaked supabase service role key is a critical security incident. It's even more dangerous than a leaked database connection string because it also gives access to Supabase's built-in auth and storage services.

How to Scan Your Codebase for a Leaked Supabase Service Role Key

1. Search Your Local Files with grep

Start by searching your entire local project for the key pattern. Supabase keys start with eyJ (base64-encoded JSON) and are often stored in .env files or hardcoded.

grep -r "service_role" --include="*.{js,ts,py,env,json,yaml,yml,toml}" .

Look for lines like:

SUPABASE_SERVICE_ROLE_KEY=eyJ...

If you find it in a client-side file (like App.tsx or a .js file served to the browser), treat it as leaked immediately.

2. Check Your .gitignore and Commit History

Even if you removed the key from your current code, it might be in your Git history. Use git log to search:

git log --all --oneline --diff-filter=A -- '*.env'

Then inspect old commits:

git show <commit_hash> | grep -i "service_role"

If you find the key in any commit, it's compromised because anyone with access to your repo can see it.

3. Scan GitHub for Leaked Keys

If your repository is public (or even private with collaborators), use GitHub's secret scanning alerts. Go to your repo on GitHub → Settings → Code security & analysis → Secret scanning. Enable it if not already. GitHub will automatically detect Supabase keys and notify you.

Alternatively, use a dedicated secret scanner like OverMCP (overmcp.com) to scan your entire GitHub org for leaked keys across all repos.

How to Check if Your Service Role Key Has Been Leaked

1. Review Supabase Audit Logs

Go to your Supabase dashboard → Logs → Audit Logs. Look for unusual API calls using the service_role key. Filter by service_role in the query. If you see requests from unknown IPs or unexpected geographic locations, your key may be leaked.

2. Check for Unauthorized Database Changes

Run a query to check for recent schema changes:

SELECT * FROM information_schema.tables 
WHERE table_schema NOT IN ('pg_catalog', 'information_schema');

If you see tables you didn't create, someone may be using your leaked key.

3. Monitor Supabase Project Usage

In the Supabase dashboard, go to Settings → Usage. Look for spikes in API requests, database reads/writes, or storage operations that don't match your app's traffic. A sudden increase could indicate a data breach.

Step-by-Step: How to Rotate Your Leaked Service Role Key

Once you confirm or suspect a leak, rotate the key immediately:

Important: After rotation, any service using the old key will fail. Make sure you update all production deployments before rotating.

How to Prevent Future Leaks

1. Use Environment Variables Everywhere

Never hardcode the key. Use .env files locally and inject environment variables in production. In your code, access it like:

const supabase = createClient(
  process.env.SUPABASE_URL,
  process.env.SUPABASE_SERVICE_ROLE_KEY
);

2. Add Supabase Key to .gitignore

Make sure your .env file is in .gitignore:

.env
.env.local
.env.production

3. Use a Secret Scanner

Use tools like OverMCP to scan your repos and codebase for secrets before they leak. OverMCP runs on every push and alerts you if a Supabase key is detected.

4. Restrict Key Usage with IP Allowlists

In Supabase, go to Authentication → Settings → Network Restrictions and add IP addresses that are allowed to use the service_role key. This limits damage even if the key leaks.

5. Enable Multi-Factor Authentication (MFA) on Your Supabase Account

If an attacker gets your dashboard credentials, they can rotate keys themselves. Enable MFA in your Supabase account settings.

Real-World Example: How a Leaked Service Role Key Cost a Startup $10,000

A developer accidentally committed a .env file containing the service_role key to a public GitHub repo. Within hours, an automated bot found it and started running SQL queries to copy all user data. The attacker then deleted the database and demanded a ransom. The startup had no backups and lost all customer data, leading to a $10,000 recovery effort and complete rebuild.

Moral: Always scan for leaked keys before pushing to public repos.

FAQ

How can I detect a leaked Supabase service_role key in my GitHub repo?

Use GitHub's built-in secret scanning (Settings → Code security → Secret scanning) or a third-party tool like OverMCP that scans all repos automatically. Also run git log --all -p | grep 'service_role' to check commit history.

What should I do if I find my Supabase service_role key in a public repo?

Immediately rotate the key in Supabase dashboard (Project Settings → API → Rotate), then update all environment variables. Remove the key from the repo and consider it compromised. Also revoke any active sessions that used the old key.

Can the Supabase anon key be used the same way as the service_role key?

No. The anon key is designed to be public and safe to expose in client-side code, but it should still be used with Row Level Security enabled. The service_role key must never be public because it bypasses all security policies.