RLS on 50+ Tables: A Supabase Row Level Security Guide

I manage 12 database projects right now. They power everything from my DTC fashion brand here in San Diego to apps I've built for clients across different industries. A few months ago, I ran a security audit across all of them.

What I found was not great.

About 30% of my database tables had security gaps. Not small, theoretical ones. Real holes where someone with basic technical knowledge could have read or changed data they had no business touching. Customer information, order histories, internal records — all of it potentially exposed.

If that's happening in my systems — and I've built 29 automation systems, written 22,000+ lines of code, and think about this stuff every single day — then most businesses running on this same technology have wide-open doors they don't even know about.

What's the Actual Problem Here?

Let me explain this with an analogy.

Imagine you run a hotel. Every guest gets a room key. In a traditional setup, there's a front desk clerk who checks your key before letting you go anywhere. Want to access the pool? The clerk checks. Want room service? The clerk checks. There's always a human gatekeeper.

The database technology I use (called Supabase) works differently. It's more like a hotel where guests walk directly to their rooms without passing a front desk. It's faster and more efficient, but it means the locks on the doors themselves are the only thing keeping people out.

Those locks are called Row Level Security, or RLS. Each "row" is a piece of data — a customer record, an order, a document. RLS is the rule that says "only the person who owns this data can see it or change it."

Here's the scary part: those locks aren't turned on by default. You have to set them up yourself. And if you don't, every single piece of data in your database is accessible to anyone who knows where to look. Not hackers using sophisticated tools. Anyone with a web browser and five minutes of curiosity.

What I Found When I Audited Everything

Across 50+ tables in my 12 projects, here's what the audit revealed:

11 tables had no locks at all. They were completely open. Anyone could read or change anything.

8 tables had locks that looked real but weren't. Think of it like a door with a lock installed, but the lock is set to "always open." The security dashboard showed a green checkmark — everything looks fine. But the rule governing access literally said "let everyone in." These got set up as temporary placeholders during development and never got replaced with real rules.

3 tables had broken locks. The rules referenced information that didn't exist or wasn't set up correctly, creating unpredictable behavior.

That's roughly 30% of my tables with some kind of problem. And every one of those problems is invisible during normal use. Your app works fine. Your customers see the right data. Everything looks correct on the surface. But underneath, the doors are unlocked.

Why This Matters for Any Business

The type of vulnerability this creates has a name: IDOR, or Insecure Direct Object Reference. In plain English, it means someone changes a number in a web address and suddenly sees someone else's data.

Imagine your order confirmation page shows yourstore.com/orders/4582. What happens if a customer changes that to 4583? Without proper security rules, they see another customer's order. Name, address, what they bought, what they paid. Scale that across your entire database and you're looking at a data breach that didn't require any hacking at all.

This is especially relevant right now because so many businesses are using AI tools to build their apps and databases. I wrote about this problem separately — AI-generated code almost never includes these security rules. The AI builds your tables, your data, your interface, and skips the locks entirely. Every. Single. Time.

How I Fixed It (And How You Can Check Yours)

The good news: once you know what to look for, fixing this is straightforward. I built a checklist that I now run before any project goes live:

1. Every table has security rules turned on
2. Every table has rules for reading, creating, editing, and deleting data
3. No rule says "let everyone in" unless the data is genuinely meant to be public
4. Every rule actually checks who's asking before granting access
5. I test by pretending to be a stranger and verifying I can't see data that isn't mine

The whole audit takes about 15 minutes per project. On one project, I found a performance issue where these security checks were slowing down page loads by 80 milliseconds. One small fix brought that down to 3 milliseconds — a 96% improvement. Security doesn't have to mean slow.

This Is Always the First Thing I Check

When I come into a new engagement — whether it's a financial advisory firm, a SaaS company, or a manufacturing business — database security is the first thing I audit. Not the AI strategy. Not the automation roadmap. The locks on the data.

Because none of the sophisticated stuff matters if your information is leaking out the back door. I've seen it happen to smart teams who were moving fast and shipping features. Security is the step that has no visible effect when you skip it — until someone exploits it.

Thinking About AI for Your Business?

If this resonated — especially if you're now wondering whether your own systems have gaps like these — I'd be happy to talk through it. I do free 30-minute discovery calls where we look at your operations and identify where AI could actually move the needle.

Book a Discovery Call