Lovable typically generates a React frontend on a Supabase backend, so its failure modes mostly land at that generated boundary — and the live preview hides them because it only ever runs as you.
Critical
Generated Supabase policies that are open by default
Lovable wires up Supabase quickly, and generated or AI-suggested policies often end up permissive (USING (true)) so the app just works in preview. That same policy lets anyone read or write the table in production.
check › In Supabase → Policies, read every generated policy; USING (true) means open.
Critical
Keys and config left in the generated client code
While iterating it’s easy to end up with more than the public anon key exposed, or a secret pasted into client-side code. Anything in the frontend ships to every visitor.
check › Check the generated client for any key beyond the public anon key.
Critical
The preview works — so it looks done
Lovable’s live preview only ever exercises the happy path, as you, the owner. It never tries a second user, a hostile input, or the /admin page without a session — which is exactly where the bugs are.
check › Has anyone tested as a different user than you?
Watch
Auth in the UI only
Generated apps often gate pages by hiding components, while the underlying Supabase queries stay reachable with the anon key. The real gate is row-level security, not the UI.
check › Can the data be read by calling Supabase directly, ignoring your UI?
Watch
Unvalidated writes from generated forms
Generated forms may insert straight to the database with no server-side validation or ownership check — letting users write rows they shouldn’t.
check › Do writes validate input and confirm the row belongs to the user?
These are the patterns, not a checklist run against your repo. The audit reads your
actual Lovable code and tells you which of these are really there — prioritized,
critical first. Or try the free 2-minute self-check →