Row-level security is on by default now. That is not the same as being protected.

Lovable has closed the gap that generated most of the early coverage. It enables row-level security by default, runs a linter that catches missing RLS after a database migration, and runs automated security checks against database configuration when your schema changes, flagging what it finds. Its agent will also produce an assessment covering auth flows, schema, RLS policies, and general posture.

That is a meaningful amount of safety net, and it is worth saying plainly rather than recycling an older story about defaults that have since been fixed. If your mental model of building on Lovable is from a year ago, update it.

Row-level security is a switch and a policy. The switch decides whether Postgres consults a policy at all. The policy decides who can see which rows. Platform tooling can turn the switch on for you and can tell you when it is off. It cannot know that a support agent should see tickets for their assigned accounts and nobody else's, because that is a fact about your business, not about your schema.

So RLS enabled with a permissive policy passes every automated check and leaks exactly as much data as RLS disabled. The linter is satisfied, the scan is green, and the table is still readable by anyone holding an API key. This is the failure mode that survives good defaults, which is why it is the one worth your attention.

Supabase's own documentation makes the underlying point: tables created through SQL do not have RLS enabled unless you enable it, and skipping that step is a documented cause of data leaks. Anywhere your schema is created outside the tool's happy path, a migration you wrote by hand, a table added directly in the dashboard, the defaults you are relying on may simply not have applied.

There is a version of this check that takes two minutes and does not require reading any policies. Create a second account. Sign in as that user. Try to read a row that belongs to the first user.

If it comes back, every row in that table is available to anyone who can authenticate, and in some configurations to anyone holding your public API key at all. If it does not, that table is doing what you think it is doing. Repeat for each table holding data that belongs to a specific user.

This works because it tests the thing you actually care about, which is behaviour, rather than the thing that is easy to check, which is configuration. It is also the same test that catches broken object-level authorisation in hand-written code, so it is worth doing whether or not a generator was involved.

Lovable raised $400M at a $13.3B valuation this month. The reason that matters to someone building on it is not validation, it is roadmap: a company at that scale will keep improving the generated defaults, and the gap between "what the platform handles" and "what you handle" will keep moving.

That is good, and it creates a specific obligation. If your security posture depends on platform defaults, you need to know which ones, because they are being changed by someone whose release notes you do not read. The properties you own explicitly, in policies you wrote and tests you run, are the ones that do not move underneath you.