Tenant taken from the client
A policy compares org_id on the row with an org_id the user can set. Membership has to come from a table the user cannot write, checked against auth.uid().
Supabase RLS security review
RLS is on. Right?
Turning on Row Level Security is the easy part. The hard part is whether every policy, view, database function and Storage bucket gives each user exactly the rows they should have, and nothing from the next customer. The Launch Security Check answers that for your whole Supabase project, with every finding confirmed by a senior engineer and a SQL fix attached.
- Price
- From US$790 fixed, for one small app; larger schemas get a fixed quote first
- Covers
- Tables, views, functions, Storage plus Edge Functions and app code that use the service-role key
- You get
- Report + walkthrough who can read and change what, ranked by impact, with SQL fixes
Get a fixed quote
Opens a pre-filled email to hello@proofmerge.com · or use the short request form below
What goes wrong
Six RLS mistakes that pass every test you click through
None of these shows up in your own app's screens. Each lets a signed-in user, or an anonymous visitor, reach rows that belong to someone else.
No WITH CHECK on writes
A using clause controls which rows you can see. Without with check on insert and update, a user can write rows into another tenant or hand a record to someone else.
Views that skip RLS
A view runs with its owner's rights unless it is created with security_invoker. A reporting view over a protected table can return every customer's rows.
Functions callable over /rpc
A security definer function bypasses RLS by design. Exposed to anon or authenticated without its own ownership check and a fixed search_path, it becomes a side door.
Roles read from user_metadata
Users can edit their own user_metadata. A policy that trusts a role or plan stored there lets anyone promote themselves. Authorization belongs in app_metadata or your own tables.
Storage not tied to the owner
A public bucket, or a policy that checks the bucket but not the folder, lets any user list or download every file. Paths need a user or tenant prefix enforced by policy.
How the review works
Every object, every role, every operation
An advisor or scanner can tell you that RLS is off. It cannot tell you whether a policy that is on matches your business rules. That needs someone to read the schema with your roles in mind.
See the sample report from a demo app →- Inventory. Every table, view, function and bucket reachable through the API, from your migrations or a schema-only dump.
- Access matrix. For anon, signed-in users and each of your roles: who can select, insert, update and delete which rows.
- Bypasses. Grants, views without security_invoker, security definer functions, and every place your code or Edge Functions use the service-role key.
- Exploit path. For each finding, the exact request an attacker would send with the public key or their own session.
- Fix. The corrected policy or function in SQL, ready for a migration.
How it works
Scope first, then a read-only review
Scope
One email or a 15-minute call to confirm the project fits the fixed price. Larger schemas get a fixed quote in writing first.
Authorization and access
You authorize the review in writing and share read-only access to the repository with your migrations, or a schema-only dump. No production data, no live keys.
Review
Automated checks across the codebase, then a senior engineer builds the access matrix and confirms what is real.
Report and walkthrough
Every finding with impact, the attacker's request and the SQL fix, an executive summary, and a 30-minute call.
The report is due within two business days of confirmed scope, agreed payment arrangements and complete access. Payment terms are agreed in writing before work starts.
The report
See the format before you commit
The sample report comes from a demo app (Next.js, Supabase and a Python agent service) with planted issues, including tables without Row Level Security and a service-role key in frontend code. It contains no client data.
Full sample report →Next.js + Supabase review · Apps built with Lovable, Bolt or Cursor
- Ranked by real exploitability. What an attacker could actually reach comes first.
- SQL, not slogans. The corrected policy, not "review your RLS".
- Redacted. Secret values found in code are never reproduced.
- Honest about scope. A list of what was reviewed and what was not.
Scope, plainly
A security review, not a penetration test
Read-only review
We review your schema, policies and code with the access you grant. We do not attack running systems or touch production.
Dashboard settings
Auth providers, redirect URLs and bucket settings are reviewed when you share them; otherwise the report says they were not checked.
Not a certification
No SOC 2 report or audit opinion. A clean report means nothing was found in the agreed scope, not that the app is secure.
FAQ
Before you write
The Supabase Security Advisor shows no warnings. Am I fine?
Keep using it; it catches tables without RLS and several risky settings. It checks that rules exist, not that they are correct for your app. A policy can be enabled, pass the advisor and still let one customer read another's data.
Our frontend is not Next.js. Does that matter?
No. RLS lives in the database, so the core of the review is the same for React, Flutter, mobile or AI-builder frontends. Tell us what calls Supabase so we know where the keys live.
What do you need from us?
Read-only access to the repository with your migrations, or a schema-only dump, plus the app code that talks to Supabase. Never send live keys or customer data.
What counts as a small app for US$790?
Roughly one application with a few dozen tables and a handful of functions and integrations. Larger schemas or several services get a fixed quote in writing before anything starts.
Can you fix the policies for us?
Every finding comes with the corrected SQL. Applying and testing the changes in your project is quoted separately on request.
Start with one short request
Tell us about your Supabase project
Roughly how many tables and functions, whether it is multi-tenant, and when you launch. You get a scope, a fixed price and a start date back by email, usually within one business day. Please do not send code or credentials yet.
Prefer email? Write to hello@proofmerge.com · Back to all services