I will security check your lovable or bolt supabase app before you launch


About this gig
Built with Lovck clean I will tell you so.able, Bolt or Cursor. It works. That was never the question.
The question is what a stranger holding your anon key can read out of it.
These tools generate policies fast, and they usually look right. But RLS is one layer. Underneath it is the Postgres grant system, above it is PostgREST, and the leaks live in the seams.
I run a multi-tenant POS on Supabase - 90 migrations, real money daily. Three security reviews found six real holes, every one past policies that were, as written, correct.
WHAT I CHECK
- Tables with RLS off, or on with no policy
- - Functions anon can execute (revoking from anon alone does NOT close this)
- - Views that bypass RLS, and the ones PostgREST quietly made writable
- - Table-wide grants, and the asymmetry nobody expects:
- a new column is DENIED for reads until you grant
- a new column is ALLOWED for writes until you revoke
HOW I PROVE IT
I log in as a real low-privilege user from your project, run the query, and show you the response. Every finding carries its query and its output. After the fix the same query runs again and returns something different.
The read-only script I use is public - run it yourself
Get to know Basel Draz
Supabase RLS and privilege audits
- FromEgypt
- Member sinceFeb 2024
- Avg. response time11 hours
Languages
English, Arabic
My Portfolio
FAQ
Do you need my production database?
No. A read-only role, or a staging copy with the same schema, is enough. The checks read catalogs, not your rows. I do not want your service role key and I will ask you not to send it. Only the Audit and Fix package needs write access, and only for the migrations listed in the report.
I did not write the code myself, the AI did. Is that a problem?
Not at all, and you do not need to understand the SQL to use the report. The top of it is written in plain language for whoever signs off, and the queries and migrations sit underneath for whoever applies them. If that is also you, I will walk you through each one.
What if you find nothing?
Then the report says so, and you have a documented baseline plus the list of everything that was tested. Run the public script yourself before ordering. If it comes back clean, message me and I will tell you honestly that you do not need this.
Is this only for Supabase?
The checks are plain Postgres and work on any Postgres 15+ database using row level security. Supabase is where they are needed most, because the anon role and PostgREST expose things people do not expect. I also sign an NDA on request, and your findings never appear in my public writing.

