THE
OPEN
DOOR.

1. Audit what is open right now

Run this in the Supabase SQL editor on every project you own. It takes five minutes and it is the check that would have caught every real-world incident cited in this article.

SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public' AND rowsecurity = false;

Every table this query returns is publicly readable and writable through the REST and GraphQL APIs right now, regardless of what your frontend appears to enforce. Do this before anything else in this guide.

2. Enable RLS and write real policies

There is a pattern that looks like RLS but does nothing. Know it so you can spot it in generated code.

-- Enable on every table, every time
ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;

-- The pattern you want
CREATE POLICY "users read own profile" ON profiles
  FOR SELECT USING (auth.uid() = user_id);

-- UPDATE needs both clauses — USING governs reads,
-- WITH CHECK governs writes
CREATE POLICY "users update own profile" ON profiles
  FOR UPDATE USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

The USING / WITH CHECK distinction matters: UPDATE policies need both, or a user can read their own row but silently overwrite it with another user's data. Add ALTER TABLE ... ENABLE ROW LEVEL SECURITY to every table-creation migration as a standing habit — not an afterthought once data exists.

3. Test from the client, not the SQL editor

The Supabase SQL editor runs as an elevated role that bypasses RLS entirely. Testing a policy there tells you nothing about what a real user can actually do. Test from the client SDK, logged in as different real accounts, and verify each policy behaves as intended. Testing as yourself while you are also the database admin is how policies that do nothing ship to production looking correct.

4. Never expose the service_role key

The service_role key bypasses RLS completely — full database access, no restrictions. It should never appear in client-side code. The most common real-world leak paths:

If you suspect a service_role key has leaked, rotate it immediately in the Supabase dashboard, then audit query logs for anything that could not plausibly have come from your own app.