Supabase RLS & Data Isolation Review
Can every customer see only their own data?
We review the tables, roles, tenant boundaries and storage policies that control who can read, create, update and delete data in your Lovable and Supabase application.
You receive evidence-backed findings, exact remediation guidance and repeatable validation steps.
- Fixed scope
- No passwords
- No blind policy changes
- Not a penetration test
Start here when permissions feel uncertain.
This review is designed for applications where:
- customers belong to separate organizations or tenants,
- owner, admin and member roles have different rights,
- RLS policies were added or changed during rapid iteration,
- users receive unexplained 403 or permission errors,
- private documents depend on Supabase Storage policies,
- server or service-role boundaries are unclear,
- you are preparing for launch or customer due diligence.
Know which boundary is working, which is not, and how to prove the fix.
The output is not a generic “security score.” It identifies the affected table, function, role, operation or storage boundary; shows the supporting evidence; ranks the business risk; and defines the test that must pass after remediation.
What is reviewed
Agreed review scope may include:
- Tenant and organization model
- Anonymous and authenticated access
- Owner, admin, member and custom roles
- Table and view policies by operation
- USING and WITH CHECK behavior
- Role or JWT-claim dependencies
- Ownership reassignment and escalation paths
- Storage buckets and object-path isolation
- Client-visible keys and service-role exposure
- Migrations and policy drift
- Direct API negative-access tests
What you receive
- Written scope and asset map
- Role and tenant access matrix
- Policy and storage inventory
- Severity-ranked findings
- Evidence and confidence for each finding
- Exact remediation recommendation
- Positive and negative validation steps
- Review limitations
- Fixed or capped remediation-sprint proposal, where justified
How the review runs
-
Scope confirmation
We agree the tables, roles, tenants, functions and storage assets to be reviewed before payment.
-
Controlled access
We use read-only or minimum-privilege access and synthetic test accounts wherever possible.
-
Review and negative testing
We inspect policies and test both allowed and forbidden paths.
-
Independent QA
Material findings are checked for evidence, severity and false-positive risk.
-
Report and walkthrough
You receive the findings, priorities, remediation options and validation plan.
This is not:
- a formal penetration test,
- a compliance certification,
- an active-breach or forensic investigation,
- a guarantee that no vulnerability exists,
- a codebase-wide security audit,
- permission to disable RLS globally.
Suspect active unauthorized access or data exposure? Do not use the normal review route. Preserve evidence and request specialist security-incident handling.
If remediation is justified
RLS Remediation Sprint
The review does not include production policy changes. Where remediation is justified, selected findings can move into a separately approved RLS Remediation Sprint with written scope, tests and rollback.
RLS review questions
More questions? Read the full FAQ →Is this a penetration test?
No. It is a scoped configuration and data-isolation review of agreed Supabase assets and application boundaries. It does not provide a penetration-test or compliance attestation.
Do you need a copy of my production database?
No. We prefer schema, policy, configuration, synthetic test accounts and the minimum evidence needed to validate access behavior.
Will you change my policies during the review?
No production change is included in the review. Any remediation is proposed separately and begins only after written approval of scope, risk and price.
Can you guarantee that the app is secure?
No. We report what was reviewed, the evidence available, the limitations and the tests performed. We do not make an unbounded “secure” or “compliant” guarantee.
What if the scope is larger than expected?
We confirm the asset and role boundary before payment. If the review reveals a materially different scope, we stop and agree a revised scope rather than silently expanding the work.