What we keep finding in AI-built apps.
Real patterns from real code, written so you can check your own app in minutes. No fear-selling — AI is a good builder; these are just the spots it doesn't think to look.
This endpoint has auth. It still lets a user hand themselves admin.
The auth check only asks who you are. It never asks what you're allowed to send. One request body with an extra field is enough to turn a normal user into an admin — and every test still passes.
Read the lesson →2026-07-20Your notifications table has RLS on. Anyone signed in can still write into someone else's inbox.
The SELECT policy on a notifications table is usually correct — you only ever see your own. The INSERT policy is where the client gets left with a wide-open with check (true), and that's the one nobody tests.
Read the lesson →2026-07-11An automated scan says the app is fine. It never looks where the bug lives.
URL scanners check your app from the outside — but RLS policies and IDOR bugs live inside the database and the route handlers, where an outside-in scan physically can't look.
Read the lesson →2026-07-08RLS was on. It still let everyone read everyone's data.
RLS enabled and the policy name sounds right — but USING (TRUE) means anyone can read everyone's data. It's the single most common breach-level hole we find in AI-built Supabase apps, and you can check your own in two minutes.
Read the lesson →2026-07-06My public view leaked every user's email. The AI called it "partial user data."
Postgres views skip RLS by default, and Supabase exposes the whole public schema through its API. How those two facts combined to publish emails for three weeks — and the two-minute check.
Read the lesson →