5 Supabase RLS Mistakes — I Broke Through Them and Fixed Them
I reproduced 5 common Supabase RLS mistakes and verified whether data actually leaks. Missing auth.uid(), policy order issues, and unchecked anon permissions — the patterns that actually got breached and how I fixed them, with code.
목차 (5)
CREATE POLICY "notes: delete own"
ON notes FOR DELETE TO authenticated
USING ((SELECT auth.uid()) = user_id);
-- Index that directly affects RLS performance
CREATE INDEX notes_user_id_idx ON notes(user_id);
When user_id is used as a condition in RLS policies, PostgreSQL filters on that column. Without an index, a Seq Scan occurs on every request. With 100 rows the difference is negligible, but past 100,000 rows the impact is immediate. Run CREATE INDEX notes_user_id_idx ON notes(user_id) alongside the policy setup.
Real-World Scenario 2 — Mixing Public Posts and Private Data in One Table
Sometimes public and private data, like blog posts, get stored in the same table. A single is_public column handles the distinction. Public posts should be readable by anyone, private posts only by the author. This uses the principle of two PERMISSIVE policies combining with OR.
PERMISSIVE policies (the default) combine with OR when multiple exist for the same operation. Two policies are enough — one for public posts and one for the author's own posts. anon users pass only the public post policy. authenticated users pass either the public post policy or the own-post policy. Another user's private posts fail both policies and return 0 rows.
INSERT and UPDATE policies must be set up separately. Read policies for public/private and write policies are separate structures. Updating the is_public value should also be restricted to the author. Checking only user_id in the WITH CHECK condition means all field modifications, including is_public, are restricted to the owner.
CREATE TABLE posts (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
user_id UUID REFERENCES auth.users(id) NOT NULL,
title TEXT NOT NULL,
content TEXT NOT NULL,
is_public BOOLEAN DEFAULT false
);
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;
-- Policy 1: public posts readable by anyone (including anon)
CREATE POLICY "posts: select public"
ON posts FOR SELECT TO anon, authenticated
USING (is_public = true);
-- Policy 2: own posts readable regardless of public/private status
CREATE POLICY "posts: select own"
ON posts FOR SELECT TO authenticated
USING ((SELECT auth.uid()) = user_id);
-- Two policies combined with OR
-- anon: sees only public posts
-- owner: sees all own posts (public + private)
-- other users: see only that user's public posts
CREATE POLICY "posts: insert own"
ON posts FOR INSERT TO authenticated
WITH CHECK ((SELECT auth.uid()) = user_id);
CREATE POLICY "posts: update own"
ON posts FOR UPDATE TO authenticated
USING ((SELECT auth.uid()) = user_id)
WITH CHECK ((SELECT auth.uid()) = user_id);
CREATE POLICY "posts: delete own"
ON posts FOR DELETE TO authenticated
USING ((SELECT auth.uid()) = user_id);
RLS Policy Checklist
I summed up the 5 mistakes in a single table. Use it as a checklist every time a new table is created.
| Mistake Pattern | Symptom | Risk Level | Fix |
|---|---|---|---|
| RLS not enabled | All data exposed | Critical | ENABLE ROW LEVEL SECURITY |
| No policies | Returns 0 rows (no error) | High | Add at least 1 SELECT policy |
| auth.uid() called directly | Slow queries | Medium | Replace with (SELECT auth.uid()) pattern |
| UPDATE WITH CHECK missing | user_id can be tampered | High | Add WITH CHECK |
| INSERT with no role specified | anon can write | High | Specify TO authenticated |
| service_role exposed to client | RLS completely bypassed | Critical | Move to server-only environment variable |
I also listed which clauses are needed per operation. INSERT and UPDATE need WITH CHECK. SELECT and DELETE only need USING.
| Operation | USING | WITH CHECK | Role (TO) |
|---|---|---|---|
| SELECT | Required | Not required | authenticated (anon too for public content) |
| INSERT | Not required | Required | authenticated |
| UPDATE | Required | Required (often missed) | authenticated |
| DELETE | Required | Not required | authenticated |
I also put together a table comparing Supabase's three roles. It covers where each is used — anon, authenticated, service_role — and what access level each carries.
| Role | Usage Environment | RLS Applied | auth.uid() | Can Be Public? |
|---|---|---|---|---|
| anon | Browser, app client | Applied | NULL | Can be public |
| authenticated | Logged-in user | Applied | User UUID | Authenticated via JWT |
| service_role | Server-only (Edge Functions, etc.) | Bypassed | N/A | Never public |
Order matters when adding RLS late to an existing project. Either create the policies before enabling RLS, or wrap them in a transaction and run them together. Enabling RLS alone without policies puts the service in a 0-row state, even if only briefly. Wrapping with BEGIN/COMMIT applies it atomically.
BEGIN;
ALTER TABLE notes ENABLE ROW LEVEL SECURITY;
CREATE POLICY "notes: select own" ON notes
FOR SELECT TO authenticated USING ((SELECT auth.uid()) = user_id);
CREATE POLICY "notes: insert own" ON notes
FOR INSERT TO authenticated WITH CHECK ((SELECT auth.uid()) = user_id);
CREATE POLICY "notes: update own" ON notes
FOR UPDATE TO authenticated
USING ((SELECT auth.uid()) = user_id)
WITH CHECK ((SELECT auth.uid()) = user_id);
CREATE POLICY "notes: delete own" ON notes
FOR DELETE TO authenticated USING ((SELECT auth.uid()) = user_id);
COMMIT;
-- RLS enablement and policy creation applied atomically
How to Properly Verify RLS
After creating policies, actual testing is necessary. The Supabase SQL Editor lets you set the role and JWT claims directly. Testing as anon or with another user's UUID is both possible. This is the fastest way to verify policy behavior at the DB level without hitting the actual API.
Two things must be confirmed. Does my data appear with my UUID? Does my data not appear with another UUID? The second is more important. In many cases own data shows up fine, but blocking access to others' data is missing.
-- 1. Test authenticated role with my UUID
SET LOCAL role TO 'authenticated';
SET LOCAL "request.jwt.claims" TO '{"sub": "my-user-uuid-here"}';
SELECT * FROM notes;
-- Only my notes should appear
-- 2. Access with another UUID (should return 0 rows)
SET LOCAL "request.jwt.claims" TO '{"sub": "other-user-uuid"}';
SELECT * FROM notes;
-- Should return 0 rows
-- 3. Test anon role
SET LOCAL role TO 'anon';
SELECT * FROM notes;
-- Should return 0 rows
Firing a curl with the anon key directly is also essential. Hitting the actual API endpoint, not the SQL Editor, gives the real picture. If the results differ from the SQL Editor, the issue may be in middleware or the Supabase proxy layer.
curl 'https://<project-ref>.supabase.co/rest/v1/notes?select=*' \
-H 'apikey: <anon-key>' \
-H 'Authorization: Bearer <anon-key>'
# Result should be []
# If data is visible, RLS configuration error
Testing with the JavaScript client is also possible. Log in a test account with supabase.auth.signInWithPassword and SELECT a row that belongs to a different account's UUID. An empty array result is correct. This approach has the advantage of testing through the exact same path as the actual app code.
Table Editor → check RLS enabled/disabled status in the table list. Authentication → Policies to see the policy list. Tables with no policies show a yellow warning indicator. Clicking the "Review" button next to each policy shows the USING/WITH CHECK conditions directly.
Frequently Asked Questions
Does enabling RLS slow down the API?
It depends on how the policies are written. Using auth.uid() directly executes the function per row and slows things down. Switching to (SELECT auth.uid()) runs it once per query. With an index on the user_id column, the performance difference becomes negligible. For complex policies, use EXPLAIN ANALYZE to check the execution plan.
When is it okay to use the service_role key?
Server-side only. That means Supabase Edge Functions, Next.js API Routes, and backend servers. It is used only in environments not exposed to the client. It must never go into a browser or mobile app. If it was exposed, rotate the key immediately at Supabase Dashboard Project Settings → API.
How do I verify that policies are applied correctly?
In the SQL Editor, change the role to anon with SET LOCAL role TO 'anon' and run a SELECT. Getting 0 rows is the correct result. Also run a direct curl against the endpoint using the anon API key. Check the policy list at Dashboard Authentication → Policies as well. If the policy name is not visible, it was not added.
What is the difference between the anon and authenticated roles?
anon is the role for users not logged in. authenticated is the role for users who logged in via Supabase Auth. Requests with an anon API key are processed as the anon role. Requests with a JWT token are processed as the authenticated role. Policies can be set separately for each role, enabling fine-grained control over public and private data.
Do I have to set up RLS on every table?
Yes. In Supabase, new tables have RLS off by default. RLS must be enabled on every table in the public schema. The Table Editor lets you check per-table RLS status at a glance. Including the ENABLE line in migration files is the way to avoid missing it.
If I enable RLS late on an existing project, will data disappear?
Data does not disappear. However, enabling RLS without policies makes all API queries return 0 rows. Policies must be created before enabling RLS, or wrapped in a transaction and run together. Wrapping in BEGIN; ENABLE ROW LEVEL SECURITY; CREATE POLICY; COMMIT; applies it atomically with no intermediate state.
How does it work when multiple policies are created?
Multiple PERMISSIVE policies on the same operation combine with OR. Passing just one is enough for access. RESTRICTIVE policies combine with AND and must all be passed. For mixed public/private data, two PERMISSIVE policies work well with OR. When the number of policies grows, check the execution plan with EXPLAIN ANALYZE.
What is the difference between USING and WITH CHECK in an UPDATE policy?
USING is the condition applied when selecting which rows to modify. The row before modification must satisfy the condition for the UPDATE to proceed. WITH CHECK validates that the result after modification still satisfies the condition. Leaving out WITH CHECK means even a row that belonged to you before can have its user_id changed to someone else afterward. Both must always be used together in UPDATE policies.
Closing
Half-configured RLS gets breached. Enabling it matters, and writing policies correctly matters too. The most common of the five mistakes are not enabling RLS and missing policies. Fixing just those two prevents most data leaks.
Run through the checklist above every time a new table is created. It does not have to be perfect. One SELECT policy and one INSERT policy with WITH CHECK is enough to cover the basics. The DELETE policy and UPDATE WITH CHECK can be added as the next step.
Adding service_role key management to the code review checklist is a good idea. If any NEXT_PUBLIC_-prefixed environment variable holds a service_role key, move it immediately. RLS configuration is never a one-time task. Making it a habit to check for policies on related tables whenever a new feature is added is all it takes.
This article reflects information as of April 2026. Some details may change with Supabase updates.