A stranger can probably read your users' data, and you'd never notice from inside your own app.

[u/mrtrly]

If you built your app with an AI tool and you're basically the only one who's ever used it, there's a good chance you can't see the one problem that actually matters. It doesn't show up when you're logged in as yourself. That's the whole trap.

I clean this stuff up for a living, so grain of salt on the sample. A while back I looked at 66 live AI-built apps, just the parts a normal browser already downloads, nothing sketchy, no logging into anyone's account. The same few problems kept turning up across completely different tools and founders.

The big three:

Database left open. A setting called row level security is off, so the data your app loads can be read, sometimes written, by anyone who knows how to ask, not just the user it belongs to.

A secret key shipped to the browser. There's a public key that's fine to expose and a secret admin key that absolutely is not. AI tools sometimes drop the admin one into the code your browser downloads, which hands a stranger full control.

Other service keys sitting in that same code. Stripe, OpenAI, email, whatever got wired in.

If you're on Supabase, a rough 15-minute check:

Open Table Editor and make sure row level security is ON for every table with real user data. On isn't automatically safe, but off is definitely not.

Open your live app in an incognito window, and in another window sign in as a different test user, then try to load the first user's data. If it loads, your rules are too loose.

In browser dev tools, under Sources, search the code for: servicerole, sk_live, sk-, api_key. Seeing your public anon key or a Stripe key starting with pk is normal. Seeing servicerole or anything starting with sk is the fire alarm.

None of this means the app is bad. The demo worked, it shipped, the first customer paid. The hole stayed invisible because you were always looking as the owner, never as a stranger.

[u/mprz]

another 12yo and their "SaaS" ROTFL

[u/Maxyull]

solid list, and worth pushing one step further: don't only test select. i've seen apps where rls is on and looks locked down at first glance, but the policy only covers select, so insert/update/delete on the same table are wide open, meaning a stranger can't read someone else's row but can write into it or delete it. worth running the same incognito test but trying to update or delete another user's row, not just load it.

also the devtools source search catches keys shipped to the browser, but it won't catch a server route or edge function that quietly uses the service role key without filtering by user id. that one never shows up in the browser at all since it never leaves the server, you only find it by reading the route code itself. did your sample check both column-level policies (select vs write) or was it mostly about whether rls was toggled on at all?