Missing RLS in Bolt.new Apps
Bolt.new generates Supabase schemas quickly but often skips Row Level Security policies. Without RLS, any user with the public anon key can read, modify, or delete all data in unprotected tables.
Scan Your Bolt AppHow It Happens
Bolt.new generates Supabase table schemas when users describe their data model. The AI creates CREATE TABLE statements and sometimes even seed data, but consistently omits or under-implements RLS policies. The pattern is predictable: Bolt creates a working app where authenticated users can read and write data through the UI. But it achieves this by not enabling RLS at all, rather than enabling RLS and writing proper policies. The app works the same either way from the user's perspective, but without RLS the data is publicly accessible. When Bolt does attempt RLS, it often creates policies only for SELECT operations, leaving INSERT, UPDATE, and DELETE unprotected. Or it creates policies that are too broad, like allowing any authenticated user to read all rows regardless of ownership.
Impact
Missing RLS means the Supabase anon key (publicly visible in the app's JavaScript) provides unrestricted access to all data in unprotected tables. Attackers don't need to authenticate; they just need the anon key and project URL. For a typical Bolt SaaS app, this exposes user accounts, private data, file metadata, and potentially payment information. The attacker can also modify or delete data, corrupting the application state or holding data hostage. Because Bolt apps often share the same architectural patterns, a vulnerability discovered in one Bolt app is likely present in many others, making them attractive targets for automated exploitation.
How to Detect
Extract the Supabase URL and anon key from your app's JavaScript bundle. Use them to make direct REST API calls to your tables. If data comes back without authentication, RLS is missing. In the Supabase dashboard, check each table for the RLS toggle. Even if enabled, review the policies to ensure they cover all operations (SELECT, INSERT, UPDATE, DELETE) and properly scope access to the row owner. Vibe App Scanner probes all accessible tables through the public API and reports exactly which tables lack RLS and which policies are missing or overly permissive.
How to Fix
Enable RLS on every table: ALTER TABLE table_name ENABLE ROW LEVEL SECURITY. This immediately blocks all access until explicit policies are added. Write policies for each operation type. For user-owned data, the standard pattern is checking (select auth.uid()) = user_id. For shared resources, create policies based on team or organization membership. Test thoroughly after enabling RLS. Each table needs policies that allow the app's normal operations while blocking unauthorized access. Sign in as different users and verify data isolation. Add a pre-deployment check that queries the Supabase management API to verify all tables have RLS enabled before shipping to production.
Frequently Asked Questions
Why does Bolt.new skip RLS?
RLS requires understanding the app's authorization model and writing specific policies. Bolt's AI prioritizes getting the app working, and disabling RLS is the easiest way to ensure database operations succeed without policy errors.
Can I add RLS to an existing Bolt app without breaking it?
Yes, but do it incrementally. Enable RLS on one table at a time and add policies that match the app's existing access patterns. Test each table after adding policies to ensure normal operations still work.
Is this issue specific to Supabase?
RLS is a Supabase/PostgreSQL concept, but the underlying problem (missing server-side access control) affects any database. Bolt apps using Firebase have similar issues with missing Firestore Security Rules.
Related Security Resources
Is Your App Vulnerable?
VAS automatically scans for missing row level security and other security issues in Bolt apps. Get actionable results with step-by-step fixes.
Scans from $5, results in minutes.