Missing RLS: The Most Underrated Breach Cause of 2026

A developer's research into migrating Firestore Security Rules to Postgres Row Level Security found that missing RLS is a leading cause of database breaches, citing CVE-2025-48757, in which 303 endpoints across 170 Lovable-built applications exposed publicly readable Supabase tables, and a March 2026 incident in which an AI platform's database was exfiltrated after an attacker found an instance without RLS enabled. The writeup notes that Supabase now enables RLS by default on new tables, but argues that manual rule translation during migrations remains an unautomated and error-prone step.

You know why there are so many breaches in databases? Perfect, me neither. Let's find out in a few minutes. Everyone worries about encryption. Almost nobody worries enough about the one thing that's actually been breaking production databases all year: a table with Row Level Security simply left off. I ran into this while researching how to safely migrate Firestore Security Rules into Postgres RLS policies for a side project. What started as "how do I translate this correctly" turned into "oh, this is the single most common way people get breached right now." Here's what I found. 🐞 CVE-2025-48757 May 2025 . 303 endpoints across 170 applications built with Lovable, an AI app-building tool, had Supabase tables publicly readable because RLS was never enabled. Not misconfigured — never turned on. 🕵️ March 2026. A database belonging to an AI platform was exfiltrated after an attacker found an instance with, again, missing RLS. Admin emails and internal schema metadata were exposed. 📡 Ongoing. Security researchers have shown that thousands of Supabase instances can be queried with nothing more than a plain curl request and the public "anon" key, dumping entire tables. Estimates put it at hundreds to thousands of misconfigured instances, globally, right now. Multiple 2025-2026 sources converge on the same line: Data protection in Supabase is roughly 90% access control, 10% encryption. Encryption isn't the weak point. The access control layer is — specifically, the step where someone creates a new table and either forgets to turn RLS on, or writes a policy that's more permissive than they think it is. This isn't unique to Supabase or even to 2026. Firebase had its own version of the exact same failure: a documented, verified leak exposed plaintext passwords and sensitive data belonging to over 1.8 million users , across more than 900 mobile apps , because Realtime Database instances were left publicly accessible — spanning health, finance, and education apps. Same root cause, different technology: a control-access layer that someone had to configure by hand, and didn't configure correctly. It's easy to get right once, and easy to forget under pressure. Supabase actually improved here in 2026 — RLS is now enabled by default on new tables, and the dashboard flags tables that don't have it. That's a real fix for the "I forgot" case. But it doesn't help with the harder case: recreating access logic that used to live somewhere else. Migrations are exactly when this goes wrong. If you're moving from Firestore, your access control used to live in Security Rules — a completely different language, with a completely different mental model, often mixing "who can access this" with "does this data have the right shape" in the very same rule. Rebuilding that from scratch, by hand, under the time pressure of a migration, is precisely the moment this class of bug is most likely to slip through. And almost nobody automates that translation. I looked. Guides for migrating off Firestore, even ones published this year, list "recreate your security rules as RLS policies" as a manual checklist item — nobody's shipping something that does it for you. rebasepro/rebase sidesteps the whole problem by having you define policies once in its own DSL instead of translating what you already have. supashim has rule translation listed as "in active development," with no public code yet. Part of why: Firestore rules genuinely mix two concerns that Postgres keeps separate — access control RLS and data shape validation CHECK constraints, column types . Translating well means untangling that mix first, not just mapping syntax A to syntax B. It's a semantic problem, not a find-and-replace one. If you're moving off Firestore or any system where security rules were baked into the data layer , don't treat the security side as an afterthought you'll "get to after the data's in." The data being correct and the access control being correct are two separate risks, and the second one is the one with a CVE number attached to it right now, not a hypothetical. A few things that seem to actually help, based on what's out there: pgrls a static RLS linter with dozens of rules for catching tenant-scoping bugs and inverted auth checks are worth running against whatever you end up with, translated or hand-written. The uncomfortable part None of the breaches above were exotic attacks. No zero-days, no clever exploits — just a curl request against a table that should have had a policy on it and didn't. The failure mode is boring, which is exactly why it keeps happening: boring mistakes don't feel urgent enough to build tooling around, until they show up in a CVE. Have you had to rebuild access control logic during a database migration? Curious whether you did it by hand, found a tool, or just... didn't think about it until later. Built at 3am, still holding the morning coffee ☕