afterbuild/ops
ERR-600/stack trace
ERR-600
Bolt.new Supabase RLS disabled — fix the data leak in 20 minutes

Bolt.new Supabase RLS disabled — fix the data leak in 20 minutes

Last updated 17 April 2026 · 7 min read · By Hyder Shah
Emergency triage — $299Free diagnostic
Direct answer

Bolt.new creates Supabase tables without Row Level Security policies. This means any authenticated user can run SELECT *on any table and read all your users’ data. The widely-reported Lovable/Supabase RLS disclosure captured the same failure pattern at scale — the same vulnerability exists in Bolt apps. The fix takes 20 minutes: enable RLS on each table and add SELECT, INSERT, UPDATE, DELETE policies. Here’s the exact SQL for the five most common Bolt table patterns.

Quick fix for Bolt.new Supabase RLS disabled — fix

Start here

Fix 1 — Enable RLS and add SELECT policy

In Supabase SQL editor, run:

ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

CREATE POLICY select_own_rows
  ON your_table
  FOR SELECT
  USING (auth.uid() = user_id);

Replace your_table with each table name and user_idwith the column that stores the owner’s user ID. Do this for every table that stores per-user data.

Deeper fixes when the quick fix fails

  1. 02

    Fix 2 — Add UPDATE and DELETE policies

    Read-only RLS isn’t enough. Add:

    CREATE POLICY update_own_rows
  ON your_table
  FOR UPDATE
  USING (auth.uid() = user_id);

CREATE POLICY delete_own_rows
  ON your_table
  FOR DELETE
  USING (auth.uid() = user_id);

    Test by signing in as a second user and attempting to modify the first user’s records — Supabase should return an empty result (0 rows affected), not an error.

  2. 03

    Fix 3 — Add INSERT policy

    New rows also need a policy:

    CREATE POLICY insert_own_rows
  ON your_table
  FOR INSERT
  WITH CHECK (auth.uid() = user_id);

    This ensures a user can only insert rows that reference their own user_id. Without it, a malicious user could insert rows with another user’s ID.

After applying the fixes

Test with two accounts in separate incognito windows. User A should never see User B’s data, and vice versa. If RLS was off since launch, rotate your anon key and assume any exposed data has been scraped.

Why AI-built apps hit Bolt.new Supabase RLS disabled — fix

Bolt.new generates Supabase SQL migration files that create tables but don’t add RLS policies. The Supabase dashboard shows these tables as “RLS disabled” in yellow — a warning that Bolt’s AI never saw.

Your app appears to work because Supabase’s Postgres RLS only enforces at the database level for authenticated requests — and your test with a single user showed correct data. With two real users, each sees the other’s data.

“Had 170+ public Lovable/Bolt apps exposing user data — all because RLS was never enabled.”
The Register, 2024

Diagnose Bolt.new Supabase RLS disabled — fix by failure mode

Check which tables need RLS policies, then apply the fix that matches your table pattern.

SymptomCauseFix
User A can see User B's orders/recordsRLS disabled or missing SELECT policyFix #1
User can edit or delete another user's dataMissing UPDATE/DELETE policiesFix #2
App shows all users' profiles, not just the logged-in user'sMissing user_id filter in SELECT policyFix #3

Related errors we fix

Still stuck with Bolt.new Supabase RLS disabled — fix?

Emergency triage · $299 · 48h turnaround
We restore service and write the root-cause report.

If any of these apply, a fixed-price security audit will save you from a public data leak:

  • →Your Bolt.new app has live users
  • →You're storing PII, emails, or payment data
  • →You've never checked the RLS column in Supabase dashboard
  • →You're seeing reports of users viewing each other's data
start the triage →
Free Rescue Diagnostic
$0
30-min call, we tell you what's exposed
Emergency Triage
$299 · 48h
Single-table RLS fix + verification
Security Audit
$499 · 48h
Full RLS, secrets, webhooks, CORS audit
Deployment & Launch
From $1,999
Productionization with RLS baked in

Bolt.new Supabase RLS disabled — fix questions

How do I know if my Bolt.new Supabase tables have RLS enabled?+
Open the Supabase dashboard, go to Authentication → Policies. Every table that stores user data should show 'RLS enabled' in green. If any table shows 'RLS disabled' in yellow, that table is publicly readable by any authenticated user. Bolt.new almost always generates tables with RLS disabled by default.
Why is RLS disabled by default in Bolt.new apps?+
Bolt.new's AI generates Supabase SQL migrations that create tables but don't add RLS policies. The dashboard surfaces a yellow warning, but that warning never reaches the AI. Your app appears to work correctly in single-user testing because there's no second user to expose the data to. With two or more real users, each one can read every other user's rows.
What SQL do I need to enable RLS on my Bolt.new tables?+
For each table: run ALTER TABLE your_table ENABLE ROW LEVEL SECURITY; then add SELECT, INSERT, UPDATE, and DELETE policies using auth.uid() = user_id as the USING clause. All four operations need separate policies — enabling RLS alone just blocks all access until policies exist.
If my Bolt.new app launched without RLS, is my data already exposed?+
Assume yes. Any authenticated user could run SELECT * on your tables via the Supabase JavaScript client and download everything. Rotate your Supabase anon key immediately, enable RLS with policies, and notify affected users if your jurisdiction requires breach disclosure (GDPR, CCPA, etc.).
Do I need RLS on tables that don't store user data?+
Reference tables (categories, product catalog, public content) can have a permissive read-only policy: CREATE POLICY read_all ON your_table FOR SELECT USING (true); but should still have INSERT/UPDATE/DELETE locked down. Never leave RLS fully disabled — it's safer to have an explicit 'allow all reads' policy than to have RLS off.
How much does a Supabase RLS audit cost?+
A single-table RLS fix runs $299 as part of Emergency Triage (48-hour turnaround). A full multi-table audit covering every table, plus anon key rotation, breach assessment, and policy tests costs $499 as a Security Audit. Both include the exact SQL migrations for your schema.
Next step

Ship the fix. Keep the fix.

Emergency Triage restores service in 48 hours. Break the Fix Loop rebuilds CI so this error cannot ship again.

Emergency triage — $299Free diagnostic
About the author

Hyder Shah leads Afterbuild Labs, shipping production rescues for apps built in Lovable, Bolt.new, Cursor, Replit, v0, and Base44. our rescue methodology.

Bolt.new Supabase RLS disabled — fix experts

If this problem keeps coming back, you probably need ongoing expertise in the underlying stack.

Sources