Tables without RLS
A table created in a migration without enable row level security is readable and writable by anyone holding the public anon key, which ships in your frontend.
Next.js + Supabase security review
Your Next.js and Supabase app works. Can one user read another user's data?
AI coding tools ship working features fast and skip the parts nobody sees: Row Level Security, server-side session checks, where secrets end up. The Launch Security Check reviews exactly those parts before you launch or start charging, and every finding is confirmed by a senior engineer before it reaches you.
- Price
- From US$790 fixed, for one small app; larger apps get a fixed quote first
- Built for
- Next.js + Supabase App Router or Pages, Supabase Auth, Postgres, Storage
- You get
- Report + walkthrough findings ranked by real exploitability, with 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 failures we see in AI-built Next.js + Supabase apps
Each of these passes a demo and a manual click-through. Each lets a stranger read or change data that is not theirs.
Policies that allow everyone
using (true) turns RLS on and leaves it open. The fix ties each policy to auth.uid() or to team membership.
Service-role key in the browser
The service-role key bypasses RLS entirely. In a client component or a NEXT_PUBLIC_ variable, it hands every visitor full database access.
Routes without a session check
API routes and server actions are public endpoints. A middleware matcher that covers only /dashboard leaves /api open.
IDs nobody checks
An export or invoice route that takes a record ID but never checks that the signed-in user owns it (IDOR). Pattern scanners miss this; the manual review looks for it.
Secrets in git history
A key deleted from the code is still in an earlier commit. The review scans the full history, not only the current files.
What the review covers
Automated checks first, then a senior engineer
Automated checks cover the whole codebase quickly. The manual pass covers authorization logic, which no pattern can judge.
See the sample report from a demo app →- Supabase (RLS review in detail). RLS on every table in your migrations, permissive policies, service-role key exposure; policy logic, grants, security definer functions and Storage policies in the manual pass.
- Next.js. Route handlers and API routes without a session check, middleware matcher coverage, secrets behind NEXT_PUBLIC_, raw HTML rendering; server actions in the manual pass.
- Secrets. Keys and tokens in code, .env files and the full git history (Gitleaks), reported with the values redacted.
- Webhooks and payments. Signature verification and replay handling for Stripe and other webhooks, reviewed manually.
- Configuration. CORS, debug flags, rate limits on login and LLM endpoints, lockfiles and pinned dependencies.
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. No production data, no live keys.
Review
Automated checks, then a senior engineer traces auth and data access, confirms what is real and ranks it.
Report and walkthrough
Every finding with location, impact and a Next.js or Supabase 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, a service-role key in frontend code and Next.js API routes without an authentication check. It contains no client data.
Full sample report →- Ranked by real exploitability. What an attacker could actually reach comes first.
- Framework-specific fixes. 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 Supabase settings
Dashboard settings (auth providers, redirect URLs, Storage buckets) are reviewed when you share them or grant read access; 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 app was built with Lovable, Bolt or Cursor. Does that matter?
No. The review reads the code and configuration the tool produced. Tell us which tool you used, because some generate the same patterns repeatedly, and it helps the scoping. What we check in Lovable, Bolt and Cursor apps.
What counts as a small app for US$790?
Roughly one application with a handful of routes and integrations. If yours is larger or has several services, you get a fixed quote in writing before anything starts.
Do you need production data or our Supabase service-role key?
No. Read-only access to the repository is enough. Never send live keys or customer data by email.
Does the review cover AI features in the app?
Basic LLM risks (prompt construction, unbounded calls, model output reaching dangerous sinks) are part of the automated checks. Agents with tools and MCP servers are covered by the AI Agent & LLM Security Sprint, quoted separately.
Start with one short request
Tell us what you built
The stack, the rough size 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