A working login screen is not proof that your database is private. Before sharing an AI-built app, test access with dummy records and three identities: signed out, user A, and user B. Try the underlying data requests, not just the visible interface. Can user B read or change user A’s records? Can a signed-out visitor retrieve something intended to be private?
Supabase’s documentation distinguishes table grants from row-level security. Grants control which operations a role may perform; RLS policies constrain which rows those operations can reach. Review both for tables exposed through your API. Keep service-role credentials server-side because they bypass RLS.
Make a small release checklist: intended public data stays readable; private records remain private; each user can perform only their intended operations. Save these checks as repeatable tests, and rerun them after schema or policy changes. Use fake data until they pass.
This is a practical baseline, not a complete security audit. A scanner result does not replace testing your own access rules.
GO TO THE SOURCE
Supabase row-level security documentation ↗Practical guidance adapted from the linked source. Recommendations are not an independently tested implementation.