Focused audit of the Supabase mistakes AI tools make most — row-level security that exists but does not bind the caller, views and functions that bypass it, columns and auth data readable through the API, policies that trust user-editable metadata, and secret keys shipped to the browser.
This audit goes past "is RLS turned on" and checks what the public anon key can actually do. It replays your Supabase migrations in order and judges the final schema, across four sections: RLS coverage (real policies, write policies that tie new rows to the caller, sensitive columns that stay unreadable), RLS bypass surfaces (views that run as their owner, SECURITY DEFINER functions anyone can call, auth.users exposed through a view, materialized views and foreign tables in the API), policy trust inputs (policies that authorize on user_metadata, which any user can edit), and keys (service-role and secret keys kept out of public bundles). Several checks mirror the Supabase database advisor lints and add what the advisor cannot see, such as the final state across migrations. If your tables only exist in the Supabase dashboard and not in your repo, those checks report unknown rather than passing, and the whole audit is skipped when the project does not use Supabase.
9
Total Checks
3
Delivery Formats
4
Categories
1
Versions
Included
Never included
Initial release. Supabase-specific audit across four sections (RLS coverage, RLS bypass surfaces, policy trust inputs, keys): reuses the Stack Scan RLS and service-role-key checks and adds seven new patterns covering write-policy WITH CHECK ownership, sensitive columns readable through the API, views without security_invoker, SECURITY DEFINER functions executable by anon or authenticated, auth.users exposed via a view, materialized views and foreign tables in the API, and policies that trust user_metadata. All new checks judge the final state after replaying supabase/migrations in order and report "unknown — schema not in repo" instead of passing when the queried tables are not created in the repo. Two deterministic detect-rg snippets (SECURITY DEFINER without a matching revoke, user_metadata inside create policy). Severity skews critical by design (the Supabase advisor lints this audit is built on are mostly security-critical); max single-check weight stays under 15 percent.
Picked by pack overlap with this audit.
Comprehensive security audit for REST and GraphQL APIs, covering authentication, authorization, input validation, and protection against OWASP API Top 10 threats.
Production-ready authentication assessment covering session management, login flow security, password handling, and OAuth integrations.
Authorization layer assessment covering access control, resource authorization, API permissions, and admin boundary enforcement.
Data handling assessment across the AI processing pipeline, covering storage, retention, PII protection, and user control over third-party model data sharing.
Safety assessment against prompt injection attacks, identifying vulnerabilities where untrusted user input might cause the AI to ignore instructions or exfiltrate data.