I'm not sure which key is which.

Decode the JWT at jwt.io. Look at the `role` claim. `service_role` is the admin key. `anon` is the safe-to-expose one.

What does the anon key look like in my code?

The anon key is a JWT starting with `eyJ...`. Its role claim is `anon`. It is safe to include in client code *if* you have RLS enabled on every table.

Critical severity · Lovable

Exposed Supabase service key on Lovable

A Supabase service role key is in your client-side JavaScript. This key bypasses Row Level Security — anyone who extracts it from your bundle has full read and write access to your entire database. The fix: rotate the key immediately in Supabase dashboard, remove every reference to it from client code, and only use it from server-side code (API routes, server components, serverless functions).

The fix for Lovable

Lovable

In Lovable, only the anon key should be in the generated frontend code. If Lovable is using the service role key client-side, tell it: 'Use only the Supabase anon key in the frontend. Move any service-role operations to a server-side function.'

Why it matters

Supabase has two keys. The anon key is safe to expose — it works with RLS. The service role key is admin. The naming is confusing and AI tools sometimes use the service role key everywhere. Once it is in your client bundle, it is game over for your database.

Confirm the fix worked

Scan your Lovable site to confirm this finding is gone.

AI prompt

Apply across your codebase

Paste this into Cursor, Lovable, Bolt, v0, or Claude Code.

My Supabase service role key is in my client-side JavaScript. First, rotate the key in Supabase dashboard. Then search my codebase for every use of the service role key and determine which ones are legitimately server-side (API routes, server actions, backend functions) and which are wrongly in client code. For client usage, replace with the anon key + proper RLS policies. For server usage, make sure the key is only in a server-only file and the env var does not have a NEXT_PUBLIC_ prefix.

FAQ

Frequently asked questions

I'm not sure which key is which.: Decode the JWT at jwt.io. Look at the `role` claim. `service_role` is the admin key. `anon` is the safe-to-expose one.
What does the anon key look like in my code?: The anon key is a JWT starting with `eyJ...`. Its role claim is `anon`. It is safe to include in client code *if* you have RLS enabled on every table.

Related fix guides

Fix these too

Supabase RLS disabled

A Supabase table without RLS is readable (and often writable) by anyone with your anon key. Here is exactly how to turn on RLS and write your first policy.

Hardcoded API key in JS

Any secret in your client bundle is public. Here is how to find them, rotate them, and move the calls server-side.

Exposed .env file

An exposed .env file is a critical leak — it contains API keys, database URLs, and secrets. Here is why it happens in vibe-coded apps and how to lock it down.

Concepts

Glossary

Row Level Security

RLS is a Postgres feature that Supabase uses to enforce per-row access control. With RLS off, the anon key gives anyone full table access.

Supabase

An open-source backend-as-a-service built on Postgres. Popular with AI tools for its simple API, but RLS misconfigurations are common.

Free tools

Spot-check this

Exposed files checker

Find .env, .git, and other sensitive files before attackers do.