RLS Write-Leak: The Silent Data Exposure That Lets Any User Modify Any Row

You enabled RLS. SELECT is locked down — users only see their own rows. You tested it, it works.

But can any authenticated user INSERT/UPDATE/DELETE any row?

Most vibe-coded apps miss this. The dashboard shows green shields. pg_policies shows policies. But the write path is wide open.

---

The Write-Leak Pattern

-- Looks correct at first glance
create policy "owner_read" on documents for select
  using (auth.uid() = user_id);

-- Missing: INSERT, UPDATE, DELETE policies!
-- Result: ANY authenticated user can write to ANY row

Postgres RLS is per-command. A SELECT policy does nothing for INSERT/UPDATE/DELETE. If you don't explicitly policy-write operations, they fall through to grants — and GRANT INSERT ON documents TO authenticated is the default.

---

The 3 Silent Write-Leak Modes

Leak Type	Policy Gap	Impact
Blind Insert	No INSERT policy + GRANT INSERT TO authenticated	Any user creates rows with any user_id — impersonation, data poisoning
Privilege Escalation	UPDATE policy only checks USING, missing WITH CHECK	User updates their row → changes user_id to victim's → now owns victim's data
Cascade Delete	No DELETE policy	Any user deletes any row — ransomware, data destruction

---

Why This Survives Testing

// Your test (passes)
const { data } = await supabase.from('documents').select()
// Returns only your rows ✓

// Attacker's test (also passes - silently!)
const { error } = await supabase.from('documents')
  .insert({ user_id: 'victim-id', content: 'pwned' })
// error = null, row created with victim's user_id

The insert succeeds silently. No error. The row now belongs to the victim. Your app shows it to the victim. The attacker just poisoned their data.

---

The Fix: Complete Command Coverage

Every table needs all four commands covered:

-- 1. Enable RLS
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

-- 2. Owner: full access
CREATE POLICY "owner_all" ON documents
  FOR ALL USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

-- 3. Org members: read only (multi-tenant)
CREATE POLICY "org_read" ON documents
  FOR SELECT USING (org_id = current_org_id());

Critical: WITH CHECK on write policies. Without it, UPDATE can change the row to violate the USING condition post-write.

---

The 9-Catalog Audit (Run in SQL Editor)

-- 1. Tables missing RLS
select c.relname from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind = 'r' and c.relrowsecurity = false;

-- 2. Tables with SELECT policy but no INSERT policy
select distinct p.polrelid::regclass as table_name
from pg_policy p
where p.polcmd = 'r'  -- SELECT only
and not exists (
  select 1 from pg_policy p2
  where p2.polrelid = p.polrelid and p2.polcmd in ('a','*')  -- INSERT/ALL
);

-- 3. Write policies missing WITH CHECK
select p.polrelid::regclass, p.polname
from pg_policy p
where p.polcmd in ('a','*','w','u','d')  -- write commands
and p.polwithcheck is null;

-- 4. Grants to authenticated without policies
-- (run per table)

Or use the free tool: github.com/cekuu35/supabase-rls-leak-demo — runs 47 checks including all write-leak vectors.

---

Real-World Impact

Case 1: SaaS with user-generated content

• Attacker inserts rows with user_id = admin_id
• Admin sees attacker's content in their dashboard
• XSS via stored content → full account takeover

Case 2: Multi-tenant B2B

• User in Org A updates org_id to Org B's ID
• Now sees/controls Org B's data
• No error, no audit log entry

Case 3: E-commerce orders

• Any user deletes any order
• Financial records destroyed
• No DELETE policy = open season

---

The "Green Shield" Illusion

Supabase dashboard shows ✅ RLS Enabled + ✅ Policies Exist.

But it doesn't verify command coverage. A table with only SELECT policy gets the same green shield as a fully locked-down table.

---

Your 5-Minute Audit

# 1. Clone free tool
git clone https://github.com/cekuu35/supabase-rls-leak-demo
cd supabase-rls-leak-demo

# 2. Run against your DB (read-only, safe)
npm install
npm run audit

Output shows:

• ❌ Tables missing RLS
• ❌ Tables with SELECT-only policies
• ❌ Write policies missing WITH CHECK
• ❌ Grants without policies
• ❌ Service role key in client bundle
• ...and 40 more checks

---

CTA

Free: Run the audit → see your write-leaks

$29 Kit: 47-check checklist + remediation SQL for every finding

$50/mo Guard: CI gate that fails build on any RLS gap

---

Next in series: "4 Security Holes Your AI-Generated Supabase App Has" — the Lovable/Cursor/Bolt patterns that leak data by default.