Supabase Row Level Security: The Complete Guide for Lovable Apps

If you're building with Lovable and Supabase, Row Level Security (RLS) is the single most important security feature you need to understand. Get it wrong, and anyone can read your entire database. Get it right, and your users' data is locked down tight.

Why RLS Matters

Here's what a hacker sees when they find an app without RLS:

// This works if RLS is disabled
const { data } = await supabase
  .from('users')
  .select('*')
 
// Returns ALL users, including emails, passwords, everything

Scary, right?

How RLS Works

Think of RLS as a bouncer at every table. Before any read or write happens, the bouncer checks:

1. Who is asking? (authenticated user, anonymous, or service role)
2. What are they trying to do? (SELECT, INSERT, UPDATE, DELETE)
3. Does it match our policy? (the rules you define)

If all checks pass, the operation proceeds. If not, it's blocked.

Step 1: Enable RLS on All Tables

Go to your Supabase dashboard, then for each table:

1. Click on the table name
2. Go to "Policies" tab
3. Click "Enable RLS"

Or run this SQL for all your tables:

ALTER TABLE users ENABLE ROW LEVEL SECURITY;
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;
ALTER TABLE comments ENABLE ROW LEVEL SECURITY;
-- Add all your tables here

Step 2: Create Basic Policies

Here are the most common policies you'll need:

Users Can Only See Their Own Data

CREATE POLICY "Users can view own data"
ON users
FOR SELECT
USING (auth.uid() = id);

Users Can Only Edit Their Own Data

CREATE POLICY "Users can update own data"
ON users
FOR UPDATE
USING (auth.uid() = id);

Anyone Can Read Public Content

CREATE POLICY "Public posts are visible to everyone"
ON posts
FOR SELECT
USING (is_public = true);
 
CREATE POLICY "Authors can see their own drafts"
ON posts
FOR SELECT
USING (auth.uid() = author_id);

Step 3: Test Your Policies

Create a test page in your app that tries to:

1. Read data that belongs to another user (should fail)
2. Update data that belongs to another user (should fail)
3. Read your own data (should work)
4. Update your own data (should work)

Common Mistakes

Mistake 1: Forgetting to Enable RLS

New tables have RLS disabled by default. Always enable it immediately after creating a table.

Mistake 2: Using Service Role in Frontend

Use the anon key for frontend operations:

// GOOD - uses anon key, respects RLS
const supabase = createClient(url, ANON_KEY)
 
// BAD - bypasses RLS, exposes all data
const supabase = createClient(url, SERVICE_ROLE_KEY)

Mistake 3: Overly Permissive Policies

Don't create a policy that allows everything:

-- DON'T DO THIS!
CREATE POLICY "Allow all"
ON users
FOR ALL
USING (true);

RLS Cheat Sheet

Next Steps

1. Enable RLS on all your tables right now
2. Create policies for each table
3. Test from the browser (not the dashboard)
4. Scan with HackNope to catch any misconfigurations

Need help? HackNope automatically detects RLS misconfigurations and generates the exact SQL policies you need.