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.
On this page (13)
- What RLS Is — Why Mistakes Happen
- Mistake 1 — RLS Itself Wasn't Enabled
- Mistake 2 — RLS Enabled but No Policies
- Mistake 3 — auth.uid() Called Directly
- Mistake 4 — UPDATE WITH CHECK Missing
- Mistake 5 — INSERT Policy with No Role Specified
- Bonus — service_role Key in the Client
- Real-World Scenario 1 — Full RLS Setup for a Multi-User Notes App
- Real-World Scenario 2 — Mixing Public Posts and Private Data in One Table
- RLS Policy Checklist
- How to Properly Verify RLS
- Frequently Asked Questions
- Closing
April 2026 · GoCodeLab
Supabase RLS — 5 Common Mistakes
I Broke and Fixed Myself
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. For each pattern I'll show how it breaks, then how to fix it.
- 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. Replace with (SELECT auth.uid()) pattern
- Mistake 4 — UPDATE WITH CHECK missing → user_id can be tampered with. USING + WITH CHECK together always
- Mistake 5 — INSERT with no role specified → anon can write. TO authenticated must be explicit
- Bonus — service_role key exposed to client → RLS fully bypassed. Isolate to server-only env vars
What RLS Is — Why Mistakes Happen
RLS is PostgreSQL's row-level access control. Unlike GRANT, which controls read/write at the whole-table level, RLS attaches a condition to each row so only specific rows can be seen. The "you can only see your own data" rule is enforced at the DB layer, server-side. No matter how sloppy the app code is, the DB layer blocks access.
Supabase Auth puts the logged-in user's UUID into a JWT token and passes it along. Calling auth.uid() inside an RLS policy retrieves that UUID. Compare it to the table's user_id column to restrict access to your own rows. Break that link and data leaks anywhere.
Supabase has three roles. anon is the anonymous user accessing without login. authenticated is a user logged in via Supabase Auth. service_role is an admin key that bypasses RLS. If a policy doesn't specify a role, it applies to all three. Not knowing this means anon users become subject to the policy and end up with unintended access.
Why do mistakes happen so often? Because RLS setup is split across stages. First you enable RLS on the table, then create policies, then specify roles and conditions inside each policy. Drop any of these and the table is silently breached or silently locked. No error message — that makes it harder to find.
- Blocks access at the DB layer regardless of app code bugs
- Even successful SQL Injection only exposes that user's data
- Maintains security in serverless/edge environments without separate authorization logic
- Policies live in the DB, not the code, so language/framework swaps don't break them
- Per-table policies are manageable from the Supabase Dashboard at a glance
- If the service_role key is exposed to the client, all RLS is void
- Wrong policy conditions can leak data even with RLS enabled
- Complex business logic (team-based permissions, hierarchical access) makes policies long and hard to manage
- Storage buckets need their own Storage RLS, separate from DB RLS
- You need a separate process to avoid forgetting RLS setup whenever a new table is added
Mistake 1 — RLS Itself Wasn't Enabled
When you create a new table in Supabase, RLS is off by default. CREATE TABLE alone makes the entire table queryable with the anon API key. The Dashboard Table Editor shows a "RLS disabled" warning, but it gets ignored often. Deploy in this state and anyone can read the table.
I tested this directly. A curl with the anon key returned all the data as-is. No authentication, content field exposed too. One missing line of RLS does it. Some devs turn RLS off during development for convenience, but it must be on before deploy.
I made a query to find tables with RLS off. It reads pg_tables directly. Once a project grows, tables multiply and some get missed. Adding this query to a CI/CD pipeline catches it automatically before deploy.
The safest pattern is to put the ENABLE line right next to CREATE TABLE in migration files. Right after CREATE TABLE, write ALTER TABLE ... ENABLE ROW LEVEL SECURITY. Habit, then it follows automatically.
CREATE TABLE notes (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
user_id UUID,
content TEXT
);
-- Fix: run immediately after CREATE TABLE
ALTER TABLE notes ENABLE ROW LEVEL SECURITY;
-- Find all tables with RLS off (result should be 0 rows)
SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public' AND rowsecurity = false;
Mistake 2 — RLS Enabled but No Policies
Sometimes you enable RLS and no data shows up at all. No error. Just an empty array []. At first I couldn't tell whether it was a data bug or a security setup issue. After staring at the wrong query for a while, I finally realized there were no policies.
If RLS is enabled and zero policies exist, PostgreSQL blocks all access by default. This is called implicit deny. It returns 0 rows with no error message, so it looks like a bug. You need at least one allow policy for data to show up.
You also need to know about policy types. The default (PERMISSIVE) policies combine with OR when there are multiple on the same operation. Passing one is enough for access. RESTRICTIVE policies combine with AND and must all pass. Most cases use PERMISSIVE; use RESTRICTIVE only when you need additional restrictions.
The Dashboard Authentication → Policies tab shows the current policy list. Tables with no policies show a yellow warning icon. If data still doesn't show after adding a policy, the SELECT policy's USING condition is often wrong. Check the condition itself first.
ALTER TABLE notes ENABLE ROW LEVEL SECURITY;
-- No policies → all blocked, returns [] with no error
-- Correct: RLS + policy together
ALTER TABLE notes ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Users see own notes"
ON notes FOR SELECT TO authenticated
USING ((SELECT auth.uid()) = user_id);
-- List policies on the current table
SELECT policyname, cmd, roles, qual
FROM pg_policies
WHERE tablename = 'notes';
Mistake 3 — auth.uid() Called Directly
When writing policies, many people put auth.uid() directly in the USING clause. It works. But there's a performance trap. This pattern calls auth.uid() once per row of the table.
10,000 rows means 10,000 auth.uid() calls. Wrap it in a subquery as (SELECT auth.uid()) and it runs once per query. The Supabase official docs recommend this pattern. The bigger the table, the wider the gap.
I compared the two with EXPLAIN ANALYZE. On a 50,000-row table, the direct call did a Seq Scan with 50,000 function executions. The (SELECT auth.uid()) version had 1 function execution and used an index scan. Query time differed by more than 4x. The gap widens when the user_id column is indexed.
Replacing existing policies is straightforward. Drop with DROP POLICY and recreate with CREATE POLICY. Or use ALTER POLICY to modify just the USING condition. Either way, it applies immediately to running sessions. From now on, write new policies with the (SELECT auth.uid()) pattern as the default.
CREATE POLICY "slow policy"
ON notes FOR SELECT TO authenticated
USING (auth.uid() = user_id);
-- Fast: called once per query (recommended)
CREATE POLICY "fast policy"
ON notes FOR SELECT TO authenticated
USING ((SELECT auth.uid()) = user_id);
-- Replace existing policy
DROP POLICY IF EXISTS "slow policy" ON notes;
CREATE POLICY "fast policy"
ON notes FOR SELECT TO authenticated
USING ((SELECT auth.uid()) = user_id);
-- Add user_id index (if missing, add it)
CREATE INDEX IF NOT EXISTS notes_user_id_idx ON notes(user_id);
Mistake 4 — UPDATE WITH CHECK Missing
UPDATE policies have two clauses: USING and WITH CHECK. USING applies when picking which rows to modify. WITH CHECK validates that the post-modification result still satisfies the condition. Drop WITH CHECK and a row's ownership can be transferred to another user.
The scenario is UPDATE-ing my note's user_id to another user's UUID. With USING only, the pre-modification row is mine, so the condition passes. With no post-modification check, it saves as-is. My note is now owned by another user.
This attack is real and reproducible. From the JavaScript client, send .update({ user_id: 'other-user-uuid' }). With a USING-only policy, the request succeeds. The target then SELECT-s their own data and gets the tampered note. Data integrity broken.
UPDATE policies must always include both USING and WITH CHECK. Even if the two conditions are identical expressions, both must be specified. USING-only checks pre-modification ownership but doesn't guarantee post-modification result. PostgreSQL's docs explicitly state this behavior.
CREATE POLICY "update own notes (vulnerable)"
ON notes FOR UPDATE TO authenticated
USING ((SELECT auth.uid()) = user_id);
-- Correct: USING + WITH CHECK both specified
CREATE POLICY "update own notes"
ON notes FOR UPDATE TO authenticated
USING ((SELECT auth.uid()) = user_id)
WITH CHECK ((SELECT auth.uid()) = user_id);
-- Attack simulation in JavaScript (with a vulnerable policy)
// const { error } = await supabase
// .from('notes')
// .update({ user_id: 'other-user-uuid' })
// .eq('id', 'my-note-uuid')
// If the policy is vulnerable, this request succeeds
Mistake 5 — INSERT Policy with No Role Specified
If an INSERT policy doesn't include a TO clause, PostgreSQL applies the policy to all roles by default. That includes anon. If WITH CHECK is loose, data can be written without login.
Especially when WITH CHECK (true) is used as a fully permissive condition with no role specified, anyone can INSERT. Spam data piles up and the table grows fast. Just specifying TO authenticated blocks it.
Even WITH CHECK (auth.uid() = user_id) isn't fully safe. In the anon role, auth.uid() returns NULL. NULL = UUID comparison is FALSE, so it looks blocked. But if user_id has no NOT NULL constraint and the client sends user_id as NULL, you get a NULL = NULL comparison. Depending on DB version or settings, that can pass.
The principle is to not depend on accidental condition pass-through. Specifying TO authenticated blocks anon-role requests before policy evaluation. The block is complete regardless of condition content. Specifying the role makes intent explicit and prevents unexpected bugs.
CREATE POLICY "insert notes (vulnerable)"
ON notes FOR INSERT
WITH CHECK (true);
-- Incomplete: NULL comparison may accidentally pass
CREATE POLICY "insert notes (incomplete)"
ON notes FOR INSERT
WITH CHECK (auth.uid() = user_id);
-- auth.uid() is NULL in anon → NULL = NULL comparison risk
-- Correct: TO authenticated + ownership check
CREATE POLICY "insert own notes"
ON notes FOR INSERT TO authenticated
WITH CHECK ((SELECT auth.uid()) = user_id);
Bonus — service_role Key in the Client
The service_role key bypasses RLS. Requests with this key can access every row. Put this key in a browser or mobile app and the entire RLS setup becomes meaningless. Anyone can open DevTools, extract the key, and access all data.
It must be managed only as a server-side environment variable. In Next.js terms, manage it as a server-side variable without the NEXT_PUBLIC_ prefix. The client should only get the anon key. If this isn't enforced, RLS is decoration. Any name like NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY in code must be fixed immediately.
If the key is already exposed, rotate it immediately at the Supabase Dashboard. Project Settings → API → API Keys lets you issue a new key. The old key expires the moment a new one is issued. An exposed key cannot be reused for any reason. Same applies if the key was committed to GitHub. Even in git history, rotate immediately.
The recommended Next.js pattern is to split the Supabase client into two. One for the browser (anon key) and one for the server (service_role key), each created separately. createBrowserClient and createServerClient handle that role. In this structure, client components can't access the service_role key at all.
- anon key → browser, app client. RLS applies. Safe to expose.
- service_role key → server-only (Edge Functions, API Routes). Bypasses RLS. Never expose.
- Next.js env vars:
NEXT_PUBLIC_SUPABASE_ANON_KEY(public) /SUPABASE_SERVICE_ROLE_KEY(private) - If service_role is in the client, RLS is void. Rotate the key immediately.
Real-World Scenario 1 — Full RLS Setup for a Multi-User Notes App
I built the full CRUD-protected RLS setup for a notes app from scratch. Decided the table structure first, then built policies per operation in order. SELECT, INSERT, UPDATE, DELETE — all four needed. The structure ends up with 4 policies on one table.
Order of setup matters. Run as: create table → enable RLS → policies. Naming policies clearly with intent helps when debugging later. "notes: select own" — table name + operation + target — is readable even six months later.
Skip the DELETE policy and other users can delete your notes. DELETE also needs a USING condition. This is one of the most-missed parts. Full CRUD coverage is required for full protection. SELECT and DELETE need only USING, INSERT needs only WITH CHECK, UPDATE needs both.
After setup I tested three scenarios. Do my notes show up under my UUID? Are my notes hidden under a different UUID? Does the anon key see nothing? All three behaved as expected. Pass these three tests and basic security is in place.
CREATE TABLE notes (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
user_id UUID REFERENCES auth.users(id) NOT NULL,
content TEXT NOT NULL,
created_at TIMESTAMPTZ DEFAULT now()
);
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);
-- 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.