Missing RLS in Lovable Apps
Row Level Security is the only thing standing between your Supabase data and the public internet. Lovable apps regularly ship with RLS disabled, leaving entire tables readable and writable by anyone with the anon key.
Scan Your Lovable AppHow It Happens
When Lovable creates Supabase tables through its AI-generated migrations, it focuses on getting the schema right for the app to function. RLS is often omitted because enabling it requires writing policies, and policies require understanding the app's authorization model, something the AI frequently gets wrong or skips. Even when Lovable does enable RLS, the policies are often too permissive. A common pattern is generating a SELECT policy that checks auth.uid() but forgetting INSERT, UPDATE, or DELETE policies. This means anyone can write to the table even if reads are protected. The Supabase anon key is embedded in every Lovable frontend. Without RLS, anyone who extracts this key can query the Supabase REST API directly and access every row in unprotected tables. This is not a theoretical risk; it has been demonstrated on hundreds of Lovable apps.
Impact
Without RLS, the entire contents of unprotected tables are publicly accessible. In a typical Lovable app this includes user profiles, private messages, uploaded files metadata, payment records, and any other data the app stores. Attackers don't just read data. They can insert fake records, modify existing rows, or delete entire tables using simple REST API calls with the publicly available anon key. This was the core issue behind CVE-2025-48757 which affected 170+ Lovable applications. The vulnerability allowed unauthenticated access to user data across multiple production apps.
How to Detect
Use the Supabase anon key (visible in your app's JavaScript) to make a direct REST API call to your database. If you get data back from a table without being authenticated, RLS is missing or misconfigured. In the Supabase dashboard, navigate to each table and check if RLS is enabled (the toggle in the table settings). Then verify that policies exist for SELECT, INSERT, UPDATE, and DELETE operations. Vibe App Scanner automatically tests every table accessible through the anon key and reports which ones lack RLS or have overly permissive policies.
How to Fix
Enable RLS on every table immediately with ALTER TABLE your_table ENABLE ROW LEVEL SECURITY. This blocks all access by default until you add explicit policies. Write policies that match your authorization model. For user-owned data, policies should check (select auth.uid()) = user_id. For shared data, use more nuanced conditions based on team membership or role. Test policies by signing in as different users and verifying they can only access their own data. Also test unauthenticated access to confirm it returns nothing. Set up a CI check or Supabase linter that flags any table without RLS enabled to prevent regressions when new tables are added.
Code Examples
Supabase RLS policy for user data
-- Table created without RLS
CREATE TABLE user_profiles (
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
user_id uuid REFERENCES auth.users(id),
full_name text,
email text
);
-- No RLS enabled, no policiesCREATE TABLE user_profiles (
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
user_id uuid REFERENCES auth.users(id),
full_name text,
email text
);
ALTER TABLE user_profiles ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Users can view own profile"
ON user_profiles FOR SELECT
TO authenticated
USING ((select auth.uid()) = user_id);
CREATE POLICY "Users can update own profile"
ON user_profiles FOR UPDATE
TO authenticated
USING ((select auth.uid()) = user_id);Frequently Asked Questions
What is Row Level Security?
Row Level Security (RLS) is a Supabase/PostgreSQL feature that controls which rows a user can access. Without RLS, anyone with the anon key can read and write all data in a table. With RLS, each query is filtered by policies you define.
Does Lovable enable RLS by default?
No. Lovable sometimes generates RLS policies, but it frequently misses tables or creates incomplete policies. You should always audit every table in your Supabase dashboard after building with Lovable.
Can I fix missing RLS without breaking my Lovable app?
Yes, but test carefully. Enable RLS on one table at a time and verify the app still works. If operations fail, add the necessary policies. The app should work identically once policies correctly reflect its access patterns.
How many Lovable apps have this issue?
Research has shown that a significant majority of Lovable apps ship with at least one table missing RLS. CVE-2025-48757 documented this pattern across 170+ production applications.
Related Security Resources
Is Your App Vulnerable?
VAS automatically scans for missing row level security and other security issues in Lovable apps. Get actionable results with step-by-step fixes.
Scans from $5, results in minutes.