Is Your Supabase RLS Broken? What Every Vibe Coder Needs to Know
By Vibe Code Janitors | 6 min read | Updated April 2026
If you built an app with Lovable, Bolt, Replit, or any AI tool that connects to Supabase, there is a significant chance your database is exposed to the public internet right now. This is the most common finding in our Lovable security checklist.
What is RLS?
RLS stands for Row-Level Security. It's a feature in Supabase (which is built on PostgreSQL) that controls which users can see, create, edit, or delete specific rows of data in your database.
Think of your database as a filing cabinet with hundreds of folders. RLS is the system that makes sure each person can only open their own folders. Without it, anyone can open any folder.
Why is this a problem for vibe-coded apps?
When Lovable or other AI tools generate a Supabase backend, they often create database tables without enabling RLS, or they enable RLS but create policies that are too permissive. The AI prioritizes getting the app to work. The result: your app works, your users can log in and do things, but under the hood, the database is wide open.
In May 2025, security researcher Matt Palmer discovered that 170 out of 1,645 Lovable-built apps had database tables with missing or misconfigured RLS. The vulnerability was severe enough to receive an official CVE designation (CVE-2025-48757).
In February 2026, another researcher found 16 vulnerabilities in a single Lovable app on the platform's Discover page, which had over 100,000 views. That single app exposed 18,000 users' data. Learn more about the broader landscape in our State of Vibe Code Security 2026 report.
How does an attacker exploit this?
Every Lovable app includes a public Supabase "anon key" in its frontend JavaScript code. This key is designed to be public. The security is supposed to come from RLS policies. If RLS is missing or misconfigured, an attacker can use that public anon key to directly query your Supabase database and pull out all data from any table.
What data is typically exposed?
Based on published research, the most commonly exposed data includes: user email addresses and names, hashed or even plaintext passwords, API keys for third-party services, payment records and billing information, user-uploaded files, and internal application configuration.
How to check if your app is vulnerable
If you are technical: Log in to your Supabase dashboard. Go to the Table Editor. Click on each table. Look for the RLS badge. If it says "RLS disabled," that table is completely open.
If you are not technical: This is exactly what our free audit covers. We check every table, every policy, and every configuration. You get a plain-English report telling you exactly what's exposed.
What to do if you're vulnerable
Enable RLS on every single table. Create policies that restrict access based on the authenticated user's ID. Remove any policies that use "true" as the condition. Move API keys out of frontend code. Test by logging in as one user and trying to access another user's data.
The bigger picture
Supabase RLS misconfiguration is the single most common critical vulnerability in vibe-coded apps. It's not a Lovable-specific problem — any app that uses Supabase and was built with AI tools is at risk. The gap between "it works" and "it's safe" is where a vibe coding cleanup specialist operates.