Missing Row Level Security linked to a string of production database breaches

A recurring failure mode

A post on dev.to argues that one of the most common ways production databases get breached this year is also one of the most mundane: a table created without Row Level Security ever being switched on.

According to the post, the clearest example is CVE-2025-48757, disclosed in May 2025. It affected 303 endpoints across 170 applications built with Lovable, an AI app-building platform, whose Supabase tables were readable by anyone. The post stresses that RLS had not been set up wrongly — it had never been turned on at all.

The author also points to a March 2026 incident in which an AI platform's database was exfiltrated after an attacker found an instance with the same gap, exposing admin email addresses and internal schema metadata. Beyond single incidents, the post cites security researchers who have shown that many Supabase instances can be queried with nothing more than a curl request and the public "anon" key, dumping entire tables; estimates run from hundreds to thousands of misconfigured instances worldwide.

The framing that emerges, attributed in the post to multiple 2025–2026 sources, is that in Supabase data protection is roughly 90 percent access control and 10 percent encryption. Encryption is rarely the weak point; the access-control layer is.

An old mistake on a new platform

This failure mode is not unique to Supabase, or to this year. The post draws a direct parallel to Firebase, where a documented and verified leak exposed plaintext passwords and other sensitive data belonging to more than 1.8 million users across over 900 mobile apps, spanning health, finance and education. The cause was Realtime Database instances left publicly accessible. The technology differs, but the root cause is identical: an access-control layer that had to be configured by hand, and wasn't.

Why migrations make it worse

The author's investigation began as a side project: working out how to translate Firestore Security Rules into Postgres RLS policies correctly. Firestore rules mix two concerns that Postgres keeps separate — who may access data, versus whether the data has the right shape, which Postgres handles through CHECK constraints and column types. That makes translation a semantic problem rather than a find-and-replace job, and recreating policies by hand under migration deadline pressure is exactly when permissive mistakes slip through.

Tooling for this is thin, according to the post. Migration guides published this year still treat rebuilding security rules as a manual checklist step. The rebasepro/rebase project sidesteps translation by having users define policies once in its own DSL, while supashim lists rule translation as in active development with no public code yet.

Supabase itself raised the baseline in 2026, the post notes: RLS is now enabled by default on new tables, and the dashboard flags tables that lack it. That fixes the "forgot to switch it on" case, but not the harder migration case — particularly where a migration creates tables outside the normal flow.

Practical guidance

For teams moving off Firestore, or any system where access rules lived inside the data layer, the post recommends:

• Default to deny for any rule you cannot confidently translate, rather than guessing at a permissive policy.
• Treat every generated policy as a draft that requires human review, never something to apply automatically.
• Run a static RLS linter such as pgrls against whatever you end up with; it includes dozens of rules for catching tenant-scoping bugs and inverted auth checks.
• Treat data correctness and access-control correctness as two separate risks, and plan for both rather than treating security as something to finish after the data lands.

Why it matters

None of the incidents described involved exotic attacks: no zero-days, no clever exploits, just an unauthenticated request against a table that should have carried a policy and didn't. That ordinariness is the problem — boring mistakes don't feel urgent enough to build tooling around until they show up in a CVE. For teams adopting Postgres-based backends, RLS coverage deserves a place on the launch checklist next to encryption, and migration projects should treat policy translation as engineering work in its own right.