RowProof home

Check who can read and change your rows

rls-audit.sql is one SQL query for Supabase and Lovable Cloud databases. It looks at your permission setup and returns a list of findings sorted by severity. It is free and you do not need to contact anyone to use it.

Download rls-audit.sql

What it checks

• Tables the API can reach with Row Level Security turned off, or turned on with no policy.
• Policies that let every row through, that also apply to anonymous visitors, or that only check "signed in" instead of "owns this row".
• Views and materialized views that can bypass Row Level Security.
• SECURITY DEFINER functions callable through the API, and those without a fixed search_path.
• Public storage buckets and storage policies without an owner check.
• Write policies that let a user create rows in someone else's name, or edit their own plan, role or credits.
• Access decided by user-editable metadata, and personal or secret-looking columns the API can read.

16 checks in total (C01 to C16). Five of them are heuristics and can misfire, so treat each finding as a lead to confirm, not a verdict.

It only reads

The script is a single SELECT over the database catalog: table settings, policies, grants, views, functions and storage bucket settings. It does not read your application rows and does not change anything. It was tested on PostgreSQL 16.15 inside a read-only transaction, where the database rejects any write. The test database is public: rls-audit-fixture.sql.

It does not check auth settings, Stripe, your function code or anything outside the database.

How to run it

1. Open the SQL editor. Supabase: SQL Editor. Lovable Cloud: Cloud, then SQL editor.
2. Paste the whole file and run it once.
3. If your API exposes schemas other than public, add them to exposed_schemas at the top of the file before running.

It assumes the standard Supabase roles (anon and authenticated) and the storage schema.

What to send for a review

Export the result table (all rows) and send it with your first message on Upwork. The output contains table, policy and function names, not your users' data. If a name is sensitive, replace it with a placeholder before sending. Never send passwords, service role keys or Stripe secret keys.