I thought the anon key was public-safe?

It is — IF RLS is enabled on every table the anon role can reach. The anon key is a JWT that grants the "anon" Postgres role. Without RLS, the anon role can read and write the entire schema.

How do I tell if RLS is on for every table?

In SQL editor: SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'. Anything with rowsecurity=false is open. Or run our scanner — it tests common table names from outside.

Critical: act in the next 60 seconds

Supabase anon key in the wrong place: when it actually matters

Your Supabase anon key (with RLS disabled) may be exposed. Here is the fastest possible recovery — three steps, no theory.

Step 01
Run "SELECT tablename FROM pg_tables WHERE schemaname = 'public' AND rowsecurity = false" to find every unprotected table.
Step 02
Enable RLS on each: ALTER TABLE public.<name> ENABLE ROW LEVEL SECURITY;
Step 03
Add a policy that explicitly allows or denies what the anon role can see.

Step 01 — Revoke

Kill the leaked credential first

Authentication → Policies. Pick a table without "RLS enabled" badge. Toggle RLS on. Then "New policy" — start with deny-all and explicitly allow only what you need.

Open Supabase RLS policies

Step 02 — Rotate

Update the new key in the right place

Server-side env vars only — never in client code, never with NEXT_PUBLIC_.

Lock down a public table

ALTER TABLE public.users ENABLE ROW LEVEL SECURITY;
CREATE POLICY "users see only their row"
  ON public.users FOR SELECT
  USING (auth.uid() = id);

Step 03 — Scan

Confirm nothing else leaked alongside it

Scan to test every common table name (users, profiles, orders, payments) for unprotected anon access.

How this usually leaks

01Lovable/Bolt scaffolds a project with anon key client-side and creates tables without RLS by default.
02Developer disables RLS during local testing and forgets to re-enable before deploy.
03New tables added later inherit no RLS unless the developer enables it explicitly.

FAQ

Frequently asked questions

I thought the anon key was public-safe?: It is — IF RLS is enabled on every table the anon role can reach. The anon key is a JWT that grants the "anon" Postgres role. Without RLS, the anon role can read and write the entire schema.
How do I tell if RLS is on for every table?: In SQL editor: SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'. Anything with rowsecurity=false is open. Or run our scanner — it tests common table names from outside.

Deeper dive

Long-term fixes for this leak class

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.

Exposed Supabase service key

The service role key bypasses all security in Supabase. If it is in your client code, an attacker has full database access. Here is how to find and fix it.

Concepts

Background

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.

See what else leaked in the same deploy

Free scan. 70+ checks. Results in 60 seconds.