Your database is open
Supabase tables with Row Level Security off, or on with a policy that says true. The anon key is in every browser. Anyone who opens dev tools can read or edit every row.
AI-native security audit for apps built in Lovable, Bolt, Replit, v0 or Cursor
You built it with AI. We audit it with AI. A scanner built for the five ways these apps fail, then agents that read every database policy, webhook and key path and write the fixes. A human runs the desk and owns the result. Report in 48 hours, all in writing, no calls.
Framework: vite | Supabase: yes | Stripe: yes | Tables: 9 CRITICAL Table orders has RLS disabled anon key in browser reads every customer's orders CRITICAL service_role key in src/lib/admin.ts bypasses all row security; ships to every visitor CRITICAL Stripe webhook never verifies signature anyone can POST "paid" and unlock the paid plan HIGH profiles policy `using (true)` for UPDATE any logged-in user can edit any other profile HIGH Admin check exists only in client state FIXED orders RLS + per-user policies (PR #1) FIXED service_role moved to Edge Function (PR #2)
Not layout. Not typos. The three things that show up after launch, when someone else is using it.
Supabase tables with Row Level Security off, or on with a policy that says true. The anon key is in every browser. Anyone who opens dev tools can read or edit every row.
A service_role key, a Stripe secret, or anything behind VITE_ / NEXT_PUBLIC_ gets shipped to the public. Deleting it later doesn't help. It's in git history and has to be rotated.
Webhooks with no signature check. Prices sent from the browser. A success page that unlocks features by itself. The builder writes the happy path and nothing else.
A specification, not a promise. Here is exactly what's in the box and what isn't.
| Included | Detail |
|---|---|
| Agent scan | Every file, for leaked keys, public env prefixes, committed .env, admin calls in client code. Purpose-built for AI-generated codebases. |
| Database review | RLS on every table, every policy read, tested as an anonymous user and as a second user. |
| Payments review | Stripe webhook verification, server-side pricing, test/live key mixing, production endpoint registered. |
| Auth and deploy | Protected routes in incognito, redirect URLs on the live domain, production build passes, env vars set on the host. |
| Your reported bug | Reproduced, root-caused, fixed or scoped. |
| Two critical fixes | Top two items, written by the agents as pull requests you can read, if each is under 30 minutes. |
| Written report | "Do these first" in plain English on top. Technical detail attached for whoever works on it next. |
| Written follow-up, 7 days | Ask anything about the report by email for a week after delivery. Answers in writing, usually same day. Flat quote for anything bigger. |
| Not included | New features, redesigns, rebuilding what the builder got wrong at the root. Those are quoted flat after the audit. |
Rescue Audit
Secure checkout by Stripe. After paying you'll see six intake questions. Repo access starts the clock. Nothing found? You'll be told that, in writing, and you can launch knowing it.
Four steps, in this order, every time.
Live URL, repo invite, what built it, what's connected, what's broken in your words, what "done" means.
Scanner first, then agents review every finding against the checklist and write the top two fixes as pull requests on a branch. A human checks the output before anything reaches you.
Plain-English priorities up top, technical detail attached. Questions answered in writing for a week. No calls to schedule.
I take myself off the repo and tell you exactly what to rotate. If there's more to do, you have a flat quote.
For UI, yes, and you should. The builder optimizes for "it works on screen." Our agents are pointed at the opposite question: how does this break when a stranger uses it? Database permissions, webhook verification, keys in the bundle. Those don't throw errors. They show up as someone else's data in your app.
It's a look, two fixes, and a report you can hand to any developer later. If nothing critical turns up you've bought certainty for launch day. Most of the time two or three things turn up that would have cost far more after launch.
Yes. Same price, you get the bug fixed and the report anyway, because the bug is usually a symptom of something on the list.
Add me as a collaborator on a branch, not an owner. Give me a read-only Supabase role. Rotate keys when we're done. That's what I'd tell you to do with anyone, and it's written into the process.
Lovable syncs to GitHub from Project Settings in about three minutes. I'll walk you through it. An app that can't be read can't be audited.
AI agents do the reading and the fixing: a scanner built for the five failure patterns in AI-generated apps, then model-driven review of every table policy, webhook and key path, then the fixes as pull requests. Nathan Lamar runs the desk: scopes each job, checks every finding before it goes out, owns the report, and answers your questions. Everything reaches you in writing so there is a record you can hand to the next developer. Email Nathanlamar08@gmail.com if you'd rather ask something first.
Forty-eight hours from now you'll have a list, two fixes, and a straight answer.