Why it matters
This is the most common serious problem in apps built with AI tools: a profiles or orders table with row-level security turned off. Anyone can download every row with one request. If the table holds personal data, that is a breach you may have to report.
How Patch checks
Only for sites you have proved you own. We take the Supabase URL and anon key your site already sends to every visitor, list the tables the API exposes, and ask each one for a single row. We record only whether rows came back, never what was in them.
This check only runs once you verify you own the site. Until then the report lists it under "what we couldn't check".
How to fix it
- In Supabase, open Table Editor and turn on row-level security for every table that holds user data.
- Add policies so people can only read their own rows, for example: using ( auth.uid() = user_id ).
- For tables that really are public, add a read-only policy and make sure they hold nothing personal.
- Run the Supabase security advisor (Database, then Advisors) and fix anything else it lists.
Your own report goes further: it names the exact pages, services and settings Patch found on your site, and with a full report you get a fix prompt to paste into Lovable, Bolt or Cursor.
Where this applies
Good security practice everywhere. Exposed personal data can trigger breach-reporting duties.