Vibe code audit
We test your Supabase policies as real users, check who can download which files from Storage, and check that every function and scheduled job refuses requests without a secret. Written for founders who built on Supabase with Lovable, Bolt or Cursor.
A Supabase security audit checks who can read and change each record and each file. We test row-level security policies as real user roles, compare Storage policies with the privacy of the records they belong to, check Edge Functions and cron endpoints for secrets, and confirm the service role key never reaches the browser.
| Area | What we test | What goes wrong when it is missed |
|---|---|---|
| Table policies (RLS) | Every table with user data, tested as owner, member, removed member and a user from another account. | A policy hides a record from a list but still returns it when asked by its ID. |
| Storage policies | Who can download each file, compared with who can see the record the file belongs to. | Files attached to a private record can be downloaded by anyone in the same account. |
| Edge Functions and cron endpoints | Each function and scheduled job checks a secret or a signed-in user and refuses when the secret is missing. | Anyone on the internet can trigger billing or reminder jobs. |
| Service role key | The key stays on the server and out of the app bundle and git history. | A key that skips every policy ends up readable by anyone. |
| Backups and restore | Backup settings, and evidence that the database and stored files have been restored together. | A backup exists, and nobody knows whether it can be restored. |
Row-level security (RLS) is a set of rules inside the database that decides which rows each signed-in user may read or change. The service role key is a master key that ignores those rules.
In one audit, row-level security was on for every family and member table, and isolation between different families held in every test. The leak was inside one family: records under a private parent did not inherit its privacy, and receipt files on private subscriptions could be downloaded by any member of the same family.
RLS on every table. Private receipts still downloadable by any family member.
Receipts sat under a family-wide storage path and the storage policy checked family membership only. A third member saw 0 rows in the private subscription list but could open the subscription by its ID. The fix binds file access to the owner of the parent record. From our anonymised sample report.
Sample report based on a real audit. Client details and figures changed.
Get the sample reportJob endpoints accepted requests whenever the job secret was unset.
Anyone could trigger the share collection and reminder jobs in the same audit. A personal finance app we reviewed had the same gap: scheduled jobs were open to anyone the moment one secret was missing. The fix fails closed and makes the secret a deployment prerequisite.
Three policies still showed one user's records to another.
Personal finance app, 56 findings, 33 high. Row-level security was switched on everywhere, so a check for "RLS enabled" passed. Testing each policy as a real signed-in user found the three that leaked.
RLS enabled means the database applies rules. It does not tell you whether the rules are right. A policy can hide a list and still return a single record by its ID, and Storage has its own policies that do not inherit privacy from your tables. Each rule has to be tested as each kind of user.
You can run a first pass yourself with two test accounts:
You give us read-only access to the code. A senior engineer reviews it across 8 areas, and the Supabase checks run under Security. You get a readiness score, findings ranked from P0 to P3 with the fix for each, a fixed-price cleanup quote and a debrief call.
Connect the repository with read-only access, or tell us where your Lovable project lives. Revoke access any time.
We apply your migrations to a clean local database and probe every policy as synthetic users. Production and customer data stay untouched.
A business summary for you and a technical report for your developer, with every finding ranked by priority.
A call with the engineer who wrote the report. Bring a partner or a technical friend.
The Supabase checks are part of the vibe code audit, which starts from $199 at a fixed price. After the audit you get a fixed-price quote for the cleanup, agreed before any work starts. You decide whether to take it. Nothing else is triggered by buying the audit.
Create at least two users in separate accounts and a second member inside one account. Sign in as each one and request every private record by its ID, then try to download each private file from Storage. A policy passes only when every user sees exactly what they should and nothing more.
Open the Table Editor or the Security Advisor in the Supabase dashboard. Both flag public tables without row-level security. That check tells you a table has rules switched on. It does not tell you the rules are correct, so test each policy as a real signed-in user as well.
No. Files in Storage have their own policies, written separately from the policies on your tables. A record can be private while its attached file is readable by everyone in the same account. We compare each storage policy with the privacy of the record the file belongs to.
It can be. One database can serve many customers when every policy filters by the customer the user belongs to, and every function checks the same thing. The risk sits in the one policy or function that forgets. That is why we test each one as users from different accounts.
Book a 30-minute call. Tell us what the app does and who should see what, and we will tell you what the audit covers.
Prefer to talk?
