Lovable exposed my Supabase key — how to fix it

Lovable generates a Supabase client file with your project URL and anon key written directly into source, and exports it to your repo. In our scan of Lovable apps this was the single most common finding, in about 1 in 6 apps. The good news: the anon key is meant to be public. The bad news: it is only safe if Row Level Security is configured, and by default it often is not.

Why it's a problem

The Supabase anon key is designed to ship to the browser, so the key being visible is not itself the problem. What makes it dangerous is that its safety depends entirely on Row Level Security policies on your tables. With RLS off or misconfigured, anyone holding that key, which is now in your public repo, can read and write every row of every table directly. Lovable does not force you to set RLS up, and nothing warns you when it is missing.

How to fix it, in order

1. 1Turn on Row Level Security, on every table. In the Supabase dashboard open Database then Tables. Enable RLS on every table and add policies that scope reads and writes to the user who owns the row. RLS with an allow-all policy is the same as RLS off.
2. 2Confirm the anon key is the anon key, not the service_role key. The service_role key bypasses RLS entirely and must never be in client code. If Lovable or a later edit put a service_role key in the client, rotate it immediately and remove it.
3. 3Move the URL and key out of source (optional but cleaner). The anon key can technically stay public, but reading it from an environment variable keeps your repo clean and makes rotation easier later. Confirm .env is gitignored.
4. 4Test it like an attacker. With the anon key from your own client, try to read a table you should not have access to. If it returns data, your policies are not restricting anything yet.

Why Lovable does this

This is a platform default, not a per-request mistake. Lovable scaffolds the Supabase client the same way every time, with the key inline at a fixed path, because it produces an app that works immediately. The security depends on a manual dashboard step (RLS) that the platform cannot do for you and most builders skip.

Stop it happening again

RLS is the whole game with Supabase. Set it up on every table the moment you create it, not before launch. Treat the anon key as public but assume nothing protects your data except the policies you wrote. Scan the repo to confirm no service_role key slipped into client code.

The quick fix

• Enable Row Level Security on every table, with policies that actually restrict access.
• Make sure only the anon key (never service_role) is in client code; rotate service_role if exposed.
• Test access with the public key to confirm your policies restrict what they should.
• Optionally move the URL and anon key into environment variables.