Row-Level Security Explained: The Supabase Setting Most Vibe-Coded Apps Get Wrong

If your vibe-coded app uses Supabase and you've never touched row-level security, there's a good chance any logged-in user can read every other user's data right now. Not through a hack. Through the default configuration doing exactly what it was built to do: nothing, until you tell it otherwise.

This is the setting we flag more than almost any other when we scan Lovable and Replit apps built on Supabase, and it's usually not because the builder did something wrong. It's because nobody explained what it actually is.

What row-level security actually does

Supabase gives every app a Postgres database, and by default, a table's data is either fully open or fully locked depending on how it was created. Row-level security, RLS for short, is the layer that decides which rows of a table a specific user is allowed to see or edit, row by row, based on who's asking.

Without it configured correctly, one of two things usually happens: either your app is wide open (any authenticated user, or worse, anyone with your API key, can query any row in your database), or it's too locked down and your own app can't read the data it needs. Neither is where you want to land.

Think of it like an apartment building. The building has a front door (your Supabase API key). RLS is what determines whether that key gets you into every apartment or only your own. Most vibe-coded apps we scan have the front door locked but no interior doors at all.

Why this specific gap is so common

This isn't a knock on any platform. Supabase is built to move fast, and RLS being off by default on new tables (until you explicitly enable it) is a deliberate tradeoff for developer speed during prototyping. The problem is that "prototyping" and "shipped to real users" often happen in the same session, and the step where you're supposed to lock it down before launch gets skipped because nobody flagged it as a launch step in the first place.

This is a version of the same story in the 5 security gaps hiding in every vibe-coded app: the issue isn't that the tools are unsafe, it's that the gap between "it works" and "it's safe for real users" is invisible until someone checks for it specifically.

Does your app actually need this fixed right now

Not every app needs the same level of RLS scrutiny, and that's the point. A single-user internal tool with no user accounts has a different risk profile than a SaaS app where user A should never see user B's data. Ask yourself:

Does your app have more than one user account? If everyone shares one login, RLS matters less (though it's still worth setting up before you add accounts later).

Does your database hold anything user-specific? Messages, orders, documents, personal details. If two different users' data sits in the same table, RLS is what keeps them separated.

Could someone find your Supabase API key? It's often sitting in your app's client-side code, visible to anyone who opens dev tools. If it is, and RLS isn't configured, that key is effectively a master key to your whole database.

If you answered yes to any of these, this isn't optional. If you answered no to all three, it's still worth setting up now, because it's much easier to configure RLS before your user base and data model grow than to retrofit it later. We cover exactly this kind of context-based prioritization in how to know what your app actually needs.

How to check and fix it

You don't need to be a database expert to do a basic check:

Open your Supabase dashboard and check each table's RLS status. Supabase shows this directly in the table editor. If it says RLS is disabled, that's your starting point.

Write policies that match your app's actual access pattern. A simple starting policy: users can only select, insert, or update rows where a user_id column matches their own authenticated ID. Supabase's policy editor supports this without needing to write raw SQL, though SQL gives you more control as your rules get more specific.

Test as a real user, not as yourself. Log in as a test account and confirm you genuinely can't see or edit another user's rows. Policies that look right on paper sometimes don't behave as expected until you test them from the user's seat.

How NEKOD fits into this

This is exactly the kind of check that's easy to miss because it doesn't show up as a bug. Your app works. Demo looks great. The gap only shows up when someone tests it from the wrong angle, or when a user notices they can see data that isn't theirs. Our 360° review checks RLS configuration as part of every Supabase-backed app we scan, scoped to what your app actually stores and who's using it, not a blanket checklist applied the same way to every project.

Key takeaways

• Row-level security controls which rows of your Supabase database each user can see or edit.
• It's often off by default on new tables, and it's easy to ship without configuring it.
• Multi-user apps holding personal data need this fixed before real users show up, not after.
• Test your policies as a logged-in test user, not only by reading the config.
• How critical this is depends entirely on what your app stores and who has access to it.

Not sure if your Supabase setup is exposed? Get your free scan and we'll check your RLS configuration along with everything else your app needs before it's ready for real users.