Tables open to the public key
The Supabase anon key is in your frontend by design. It is only safe if every table has Row Level Security. One table without it is readable by anyone who opens the browser console.
Security review for AI-built apps
You built it with Lovable, Bolt or Cursor. Before real users sign up, check what the AI skipped.
AI app builders produce working screens, logins and databases in an afternoon. What they do not do is decide who may see which data. In 2025 a researcher checked 1,645 public Lovable showcase apps and reported 170 whose Supabase tables could be read or changed with nothing more than the public key shipped in the frontend (CVE-2025-48757). The Launch Security Check is the review that catches this before launch, with every finding confirmed by a senior engineer.
- Price
- From US$790 fixed, for one small app; larger apps get a fixed quote first
- Built with
- Lovable, Bolt, Cursor, Replit, Claude Code Supabase or Postgres backends
- You get
- Report + walkthrough findings ranked by real exploitability, with fixes you can paste back into your builder
Get a fixed quote
Opens a pre-filled email to hello@proofmerge.com · or use the short request form below
What goes wrong
Six things AI builders get wrong that a demo never shows
Your app looks finished when you click through it. Each of these lets a stranger read or change data that is not theirs, without touching your screens.
Rules that say yes to everyone
A policy written as using (true) switches RLS on and still lets everyone in. Each rule has to tie rows to the signed-in user or their team.
The admin key in the browser
The service-role key ignores every rule. Pasted into frontend code or a public environment variable, it gives every visitor full control of your database.
Functions anyone can call
Edge Functions, API routes and database functions that run without checking who is calling, often because the builder added them in a hurry for one feature.
Records fetched by ID
An invoice, export or profile page that loads any record whose ID you give it, without checking it belongs to you. Scanners rarely see this; reading the code does.
Keys left behind
An API key removed from the code is still in an earlier commit or a build log. The review scans the full history and reports what to rotate.
Why a person, not only a scanner
A scanner sees what is open. A reviewer sees what should not be.
Automated scans are a good first step, and the review runs them too. They cannot tell whether a team member should see another team's invoices, or whether an admin page checks that you are an admin. That depends on your business rules, so a senior engineer reads the code.
See the sample report from a demo app →- Database rules (how we review RLS). RLS on every table, policy logic against your actual roles, grants, database functions and Storage buckets.
- Keys and secrets. What ships to the browser, what sits in environment variables, and the full git history (Gitleaks), with values redacted.
- Endpoints. API routes, server actions and Edge Functions without an authentication or ownership check.
- Sign-in. Redirect URLs, magic links and password reset flows as configured in your project.
- Payments and webhooks. Signature checks and replay handling for Stripe and other webhooks.
- AI features. Prompt construction, unbounded model calls and model output reaching dangerous places.
How it works
Scope first, then a read-only review
Scope
One email or a 15-minute call to confirm the app fits the fixed price. Larger apps get a fixed quote in writing first.
Authorization and access
You authorize the review in writing and grant read-only access to the repository your builder syncs to. No production data, no live keys.
Review
Automated checks, then a senior engineer traces sign-in and data access, confirms what is real and ranks it.
Report and walkthrough
Every finding with location, impact and a concrete fix, written so you can apply it yourself or paste it into your AI builder, plus 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, a service-role key in frontend code and API routes without an authentication check. It contains no client data.
Full sample report →5-page executive summary · Next.js + Supabase review in detail
- Ranked by real exploitability. What an attacker could actually reach comes first.
- Fixes you can apply. SQL for the policy, code for the route, not generic advice.
- 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 code and configuration with the access you grant. We do not attack running systems or touch production.
Your builder's settings
Project settings in Supabase or your builder (auth providers, redirect URLs, Storage buckets) 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
My builder has its own security scan. Is that enough?
Run it; it catches common misconfigurations quickly. It cannot know your business rules, such as which users may see which records, so it cannot tell a correct policy from a wrong one that happens to look valid. That judgement is what the manual review adds.
How do you get access to code my builder generated?
Most AI builders can sync the project to a GitHub repository or export it. Read-only access to that repository is enough. Do not send live keys or customer data.
I am not a developer. Will I understand the report?
Yes. Each finding starts with what could happen in plain words, then gives the technical fix. The 30-minute walkthrough is there for questions.
What counts as a small app for US$790?
Roughly one application with a handful of pages, tables and integrations. If yours is larger or has several services, you get a fixed quote in writing before anything starts.
Can you fix what you find?
The report gives a concrete fix for each finding. Hands-on fixing is quoted separately on request.
Start with one short request
Tell us what you built and with which tool
The builder you used, the backend 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