I had RLS enabled on a Supabase project and data still leaked. A single anon API key read another user's entire notes table. No error message. The problem was that I'd only configured half of it. It took two hours to find what was missing. RLS (Row Level Security) is PostgreSQL's row-level security feature. The simple way to picture it: a lock on every row of a table. Supabase ships it by default, but if the setup is half-done, it gets quietly broken. This is the 5 mistake patterns I found while reproducing real attack scenarios myself. Block these five and you stop most data leaks. The difference is one line of code, one policy. Quick Look Mistake 1 — RLS itself wasn't enabled → table fully public. ALTER TABLE ... ENABLE ROW LEVEL SECURITY required Mistake 2 — RLS on, no policies → returns 0 rows (silent failure). At least 1 policy required Mistake 3 — auth.uid() called directly → re-runs per row, slow.…