Last time we turned the lock on (RLS, the bouncer at every row of your database). A bunch of you wrote back with the obvious next question:
okay, I flipped it on… but how do I know it actually worked?
This is the right question, and almost nobody asks it. Here's the uncomfortable truth: you have been "testing" your app this whole time, and your test has a bug in it. The bug is you.
Why "it works for me" isn't a test
Every time you open your app, you're logged in as you. You see your data, it loads, everything looks fine. So your brain files it under "works."
But security isn't about whether you can see your data. It's about whether a stranger can see it too. And you can't find that out by being yourself.
Think of it like checking a door lock by opening it with your own key. It opens every time. Congratulations, you've proven nothing. The real test is handing the key to someone who shouldn't have it, or walking around the back to see if a window's open.
So testing security comes down to one move: stop being yourself.
The good news
You don't need to know how to code, and you don't need to "write a test" in the engineer sense. You need to become a second person and try to snoop. That's it.
Here are three checks, from easiest to most honest. Do the first today. The third is the one that actually proves it.
Test 1 — The Two-Account Test (2 minutes)
Sign up for your own app a second time, with a different email. Call it User B.
As User A, create something private: a note, an order, a profile, whatever your app stores.
Now log in as User B and go looking for User A's stuff. Open the page where it would show up. Try the obvious things.
Pass: User B sees nothing of User A's. Fail: User B can see, or worse edit, data that isn't theirs.
This catches the loudest problems. If your app is wide open, this is often where you'll feel the floor drop out.
Test 2 — The Network Tab Test (5 minutes)
Your browser will show you exactly what your app sends and receives. You just have to look.
Open your app, then open developer tools (right-click → Inspect, or F12).
Click the Network tab. Refresh the page.
Click on the requests and look at what comes back.
Two things to watch for:
Data that isn't yours. Sometimes an app correctly hides other people's data on screen but still downloads all of it, and just doesn't draw it. The screen looks fine. The Network tab tells the truth.
Keys that shouldn't be there. While you're in dev tools, go to the Sources tab and search your code for
sk_. That prefix is a secret key (Stripe and others). If it shows up in the browser, anyone who loads your site can read it. That one's a 20-second check and a very bad surprise if you skipped it.
Test 3 — The honest one (and why Test 1 can lie to you)
Here's the part nobody tells beginners, and it's the most important paragraph in this email.
Test 1 can pass even when your database is wide open.
How? A lot of AI-built apps filter data in the app code ("only show rows where the id matches the logged-in user"). That makes the screen look correct. But the lock you actually care about lives one layer deeper, in the database itself. If the database lock (RLS) is off, the app is politely choosing not to show other people's data, while the door behind it is unlocked. Anyone who skips your app and talks to the database directly walks right in.
So the real test skips the app entirely and asks the database itself: "hey, I'm User B. give me User A's data." If the database hands it over, you have a leak, no matter how clean the screen looked.
You don't have to do this by hand. Two accessible ways:
Supabase Security Advisor (free, built in). In your Supabase dashboard, open Advisors → Security. It will literally list tables with RLS off and other red flags. Start here. It takes one click and it's the fastest gut-check there is.
Ask the database directly. If you're a little braver: Supabase gives every project a public URL and the anon key. A single request to that URL, asking for a table you shouldn't be able to read, tells you everything. If rows come back, RLS isn't doing its job. (If that sentence felt like a foreign language, that's fine — that's exactly the gap I'm building to close.)
The one rule to remember
You don't need to write tests. You need to stop trusting the version of you that's already logged in.
Make a second account. Look in the Network tab. Run the Security Advisor. If anything that isn't yours comes back, that's your leak, and now you found it before a stranger did.
If this was useful, forward it to the one person you know who shipped something with AI and has never opened their database settings. They'll thank you later.
I'm building SnapDeck — a tool that runs all of these checks on your project for you, locally, and tells you in plain English what's exposed. It's not out yet. Reply "early access" and I'll put you on the list.
P.S. — what did you build, and on what stack (Supabase? Firebase? something else)? Hit reply and tell me. I read every one, and your answer usually becomes the next issue.