Example report
Sample data showing what a detailed Preflight report looks like.
Detailed findings revealed.
Anonymous-readable rows found
2 checked table(s) returned evidence that anonymous visitors can read existing rows.
Manual check only tested the table names entered. It did not scan the whole project.
Checked-table findings
These are behavior checks using the public anon key. They do not prove full project security.
categorieshighAnonymous visitors can read at least one existing row from this checked table.
lead_submissionscriticalAnonymous visitors can read at least one existing row from this checked table.
Marked critical because the table name suggests likely user, profile, lead, contact, payment, order, message, invoice, subscription, or customer data.
What to do next
- Review the flagged tables in Supabase.
- If a table should not be public-readable, enable RLS and remove broad SELECT or ALL policies from the public role.
- If a table is intentionally public, mark that decision as expected and keep it documented.
Want help fixing the flagged tables?
I can review your Supabase RLS policies, explain what is intentionally public, and send a before-and-after fix report.
Starting at $149 for small projects. Larger apps quoted after review.
Request manual auditSample read-only trace
categoriesreadableHTTP 2060-5/271lead_submissionsreadableHTTP 2060-0/1profilesnot flaggedHTTP 200*/0blog_postsnot flaggedHTTP 200*/0No writes were attempted. No row contents were read or stored. Grade A means no anonymous-readable rows were found in the checked tables, not that the whole Supabase project is secure.