What if my Supabase service_role key is in the front end?
Treat it as leaked: anyone who opens your site can read it and get full access to your database, with row-level security bypassed. Rotate it now, then move every call that needs it to the server.
23.8 million secrets leaked on public GitHub repositories in 2024, and 70% of the secrets leaked in 2022 were still valid.
How to check
- Open your live site, open the browser dev tools, and search the loaded JavaScript for service_role or for the start of your secret key.
- Search your repo, including its history, for the key and for files like .env that were committed.
- Look for env variables with a public prefix, like VITE_ or NEXT_PUBLIC_, that hold a secret. Those are built into the bundle.
What to do
- Replace the key in the Supabase dashboard under API keys. A legacy service_role key can only be replaced by moving to the new secret keys or rotating the JWT secret.
- Move the code that needed it into an edge function or server route.
- Check the database and auth logs for access you don’t recognise.
- Add a check in CI that fails the build if a secret appears in the bundle.
Why AI tools do this
When a query fails because of row-level security, the fastest way to make the error go away is to use the key that ignores security. An AI agent asked to make it work will sometimes do exactly that.