Supabase Row Level Security Policies: The Right Setup for Vibe-Coded SaaS Apps

TL;DR: Your Supabase app may be leaking data right now. RLS is the fix. Most AI tools skip it. Here is how to check — and how to close the gap fast.

If you built your product with an AI tool and shipped it on Supabase, your row level security policies are the single line between "private data" and "public data." Most vibe-coded apps get this wrong — and they ship anyway.

AI tools write code that works. They don't always write code that holds up. Supabase RLS is the layer those tools skip most. The risks are real. 31 of 47 vibe-coded apps we scanned had RLS disabled.

Check your own setup right now with the free scan. No code access. No install. 60 seconds. Start there, then read the rest.

The Three States Your RLS Can Be In

Most founders think of RLS as a binary: on or off. It's actually three states:

• RLS off: any logged-in user can read every row in every table. The anon key is a master key.
• RLS on, no policies: Postgres blocks all requests. Your app returns null. Features break. You think it's a frontend bug.
• RLS on, correct policies: each user sees only their own rows. This is the goal.

Most vibe-coded apps live in the middle state. RLS is "enabled." The toggle is green. The founder thinks the job is done. But the AI wrote USING(true) to silence errors. That rule lets every user in. It defeats the whole point.

The Two Ways RLS Fails Silently

Failure 1: RLS On With No Rules Set

You flipped RLS on. You never wrote a policy. Postgres blocks all access. Your AI-generated frontend catches the empty response and either shows a blank state or falls back to cached data. The app "works" in testing. In production, real users see each other's data or see nothing at all.

Failure 2: USING(true) Shortcuts

The AI wrote a policy to stop the errors. It wrote USING(true). This is a valid Postgres policy. But it means "allow all rows for all users." It's the opposite of security. It looks fine in the Supabase dashboard. It leaks all your data.

The fix is one line: swap USING(true) for USING(auth.uid() = user_id). That scopes each query to the user's own rows.

The Right Rule for Each Table

For any table that stores user data: turn RLS on in the Supabase dashboard, then add one policy per action. This is the SELECT policy:

-- One rule per action (SELECT, INSERT, UPDATE, DELETE)
CREATE POLICY "select_own" ON public.your_table
  FOR SELECT USING (auth.uid() = user_id);

Copy the same pattern for INSERT, UPDATE, and DELETE. Each one scopes to the user's own rows.

Apply this to every table with a user_id column. Tables with no user data — lookup tables, public configs — can keep RLS off. But any table touched by user actions needs this.

What Vibe-Coded Platforms Leave Open

Lovable — builds Supabase fast. RLS is rarely in the first scaffold. See our Lovable Audit for the gaps it leaves.

Bolt.new — RLS is off in most Bolt projects. Often the secrets leak in the client bundle too. See our Bolt Security Audit.

Cursor / Replit — missing auth on API routes is the most common issue. USING(true) shortcuts are frequent.

Our Supabase Audit covers RLS, service_role leaks, JWT checks, and bucket access.

If you used any of these platforms, your Supabase RLS config deserves a direct check. The builder optimized for "it works," not "it holds."

What Comes After the Free Scan

The free scan gives you a Launch Readiness Score. It flags the top issues across all four scan areas. RLS issues show up under Security as P0 or P1 based on what data is at risk.

Want a full fix list with time per issue? The Launch Readiness Audit ($499) covers every gap. Want the fixes done as PRs you approve? The DFY Technical Setup handles that. RLS is part of the full auth fix package.