built it on lovable or bolt? audit it before you ship.

A post went round Reddit this week that I think a lot of people quietly recognised:

"I built 2 apps with Lovable / Bolt — both had security issues before launch. Anyone else run into this? How did you handle it?"

Yes. Everyone. This is the default outcome, not bad luck.

AI app builders — Lovable, Bolt, v0, Replit Agent — are genuinely incredible at turning a sentence into a working, deployed app. What they are not good at is the unglamorous bit: shipping safe defaults. They optimise for "it renders in the preview and the happy path works," because that's what you asked for and what you can see. The security posture is invisible until someone goes looking — and on a public URL, someone always does.

The good news: the failures are boringly predictable. Three of them account for most of what bites people.

the big three

1. row-level security is off (or wide open)

Most Lovable/Bolt apps are backed by Supabase. Supabase's whole authorisation model is row-level security (RLS) — per-row policies that decide who can read or write what. If RLS is disabled, or a policy is using (true), then your app's anon key — which ships to every browser — can read and write every row in the table. Other users' data, other users' orders, the lot.

AI builders frequently scaffold tables and forget to enable RLS, or write a permissive policy to make the feature work and never tighten it. You won't notice, because your session looks fine. An attacker with your public anon key (it's in your JS bundle — it's meant to be) and 10 minutes will notice.

2. the service-role key in the browser

Supabase gives you two keys: the anon key (safe for the client) and the service-role key (bypasses RLS entirely — full database access, god mode). The number one catastrophic mistake AI builders produce is putting the service-role key somewhere it reaches the browser: a NEXT_PUBLIC_-prefixed env var, a client component, a hardcoded string. Now anyone who views source has unrestricted access to your entire database. RLS doesn't even enter into it.

3. nothing actually checks auth

/admin, /dashboard, /account, your /api/* routes — they look gated because there's a login screen. But the login screen is UI. If the route handler itself doesn't verify the session, anyone who knows the URL can hit it directly. Same story for webhooks (Stripe, etc.) with no signature check — anyone can POST a fake "payment succeeded" event.

None of these throw an error. None of these break the preview. All of them are live the moment you share the link.

the part people get wrong: "can I even audit a Lovable/Bolt app?"

Yes — and here's the bit worth internalising: you audit the code, not the builder.

Lovable and Bolt both sync your project to a GitHub repo (and let you export it). You almost certainly already open that repo in Cursor or Claude Code for the bits the builder can't do. That's where the audit happens:

build in Lovable / Bolt → it syncs to GitHub (or export it) → open the repo in Cursor / Claude Code → run the audit there

That's where Fizzgig lives. It's a set of audit tools that plug into your AI editor over MCP. You don't run it inside the builder — you point it at the code the builder produced, from the editor you already use. Ask your AI:

"what fizzgig tools do you have access to?"

…then:

"use fizzgig to scan this repo for hardcoded secrets and check my Supabase RLS policies"

the four tools that catch the big three (all free)

rls_checker — reads your Supabase migration SQL and flags RLS that's disabled, using (true), or missing the with check clause that gates writes. The #1 finding.
secret_leak_finder + env_auditor — catch the service-role key (and any other credential) leaked into client code or behind a NEXT_PUBLIC_ prefix.
auth_flow_trace — flags protected-looking routes with no detectable auth check, and webhooks with no signature verification.

These four are on the free tier. There's no reason not to run them before you share the URL.

the one-minute habit

You don't need a security team. You need a thirty-second ritual:

Sync your Lovable/Bolt app to GitHub, open it in Cursor or Claude Code.
Add Fizzgig (one config block — quickstart).
Before you share the link, ask your AI to run the RLS + secrets + auth checks.

The Reddit poster found their issues before launch and asked how to handle it. This is how: make "did I leave the database open?" a question your editor answers automatically, every time, instead of a thing you find out from a stranger.

Build fast. Just don't ship the database keys to the browser while you're at it.

Built it on Lovable or Bolt? Audit it before you ship.