Guide Lovable and Bolt

The security scan keeps flagging the same issue after the fix. Why?

By the PatchAndShip team Last verified:

Short answer

When a security warning keeps coming back after the AI "fixed" it, check three things. First, are you looking at results from an older version of your app? Second, is the warning about data you actually want to be public? Third, did the fix really change your database? Rerun the scan with the builder's own scan button, not a chat prompt, and then test the live app with a second account. A clean scan alone doesn't prove strangers can't read your data.

Do these free steps first

1. Rerun the scan the right way

  • Lovable: "Scan results are tied to a specific version of your code." After your project changes, older findings stay visible with a clock icon until you run that scan again. The Deep scan doesn't run on its own, so start it again after a fix. "Both scans are free and do not consume credits." Asking Lovable in chat to review your app's security consumes credits and doesn't update the scan results.
  • Bolt: Bolt says: "Always use the Run security audit button in the Publish menu to audit your project, since this option doesn't use tokens." Prompting Bolt to audit your project decreases your token balance. For a Bolt database, "Any time you update your database, open the Security page again to check for new issues." If your Bolt app uses your own Supabase project, run Supabase's Security Advisor again too.

2. Ask: is this data meant to be public?

Some warnings are about tables you made public on purpose, like a public list of products.

  • Bolt flags RLS Policy Always True "even when public access is what you want." Bolt says the warning "is acceptable only if you're comfortable with every visitor being able to change or delete that data." If visitors should only view the data, or only submit it, ask Bolt for that instead. If the data should be private, add sign-in.
  • Lovable lets you ignore a finding and pick a reason, such as "This is intended". Lovable says: "Ignoring findings should be a deliberate decision." You can unignore it later.

If the table holds anything private (emails, orders, messages), don't ignore the warning. Fix it.

3. Check what the fix actually did

  • Lovable's advice: "Always review the changes Lovable makes and test them thoroughly." In Bolt, version history can take your project back to before a fix. If your database is on Supabase, that won't undo database changes: Bolt says restoring an earlier version "will not change your current Supabase databases."
  • If a fix turns on Row Level Security (RLS) without adding a rule (a policy), Supabase returns no rows through the API until you create policies. Your app can suddenly show empty lists even though the data is still there. That's a sign the fix needs a policy, not a reason to turn RLS off.
  • If the app shows a "permission denied" error instead, the table is missing a grant. Supabase: "A missing grant returns a permission error… a policy that matches no rows returns an empty result."

Then test the live app. Lovable's scans read your code and configuration. They don't send live requests to your app. Bolt's database check uses the same checks as Supabase's Security Advisor. If your app's database is on Supabase, here's how to see what a real user can reach:

  1. Sign up as two test users, A and B.
  2. As A, create a private row.
  3. As B, ask for A's row through the API with B's access token. You want an empty list: []. Make sure A's row really exists first.

Don't test in Supabase's SQL editor. By default it runs as the postgres role, which "bypasses Row Level Security", so it shows everything.

4. Watch your free fixes and credits

  • Lovable: "Fix actions draw from your account's 10 free fixes". Each free fix comes back 24 hours after you use it, and further fixes consume credits. "Your workspace needs at least one credit to start a fix."
  • Bolt: "Neither the audit nor its fixes use your tokens." The project audit is on paid plans and allows up to 30 audits per day. The database security check is on all plans.

5. Know when to stop

If the same finding is still there after a rerun, a review and a test, stop spending fixes on it. Lovable itself says automated scans "cannot guarantee complete security", and for apps handling sensitive data or critical functionality it suggests you "consider an additional professional security review."

Where we can help

  • Instant check (free, no signup): paste your URL at patchandship.com/check.html. It shows the result on screen in a few seconds. It reads your homepage only, follows up to 3 redirects, loads up to 10 of your site's own JavaScript files (never third-party scripts) and runs 5 security header checks. It never logs in or touches your database, so it can't clear a database warning or confirm a fix. Critical and High details stay hidden until you prove you control the site with a one-time code in a .well-known file, a homepage meta tag or a DNS TXT record. Email is never accepted as proof. It doesn't store your results, page contents or any key it finds. It keeps a short log entry for up to 1 day and a hashed copy of your IP address for up to 24 hours.
  • Emailed mini check (free, for app owners, or someone the owner has authorized): ask for one. We run it by hand and email you a one-page summary within 24 hours. It's passive too and runs no database queries.

For Lovable apps (on Lovable Cloud or your own Supabase project) and Bolt apps on Supabase:

  • Security Fix, $149: every critical issue on our checklist fixed within 48 hours of working access. Here, critical means RLS disabled or misconfigured, public storage buckets holding private files, and exposed secret keys.
  • Fix & Deploy, $249: fixed and live on your host within 48 hours. Lovable apps go to Vercel, Netlify or Lovable hosting. Bolt apps go to Vercel or Netlify. On Fix & Deploy, misconfigured environment variables and auth redirects also count as critical.

Otherwise, a full refund if you ask within 14 days of purchase. "Critical" and "live" are defined in our Refund Policy.

AI agents run the checks and a human engineer approves every change. It's not a penetration test, a security guarantee or a compliance certification. Details: Secure your Lovable app or Secure your Bolt app.

FAQ

Why does Lovable still show the warning after it fixed it?

Scan results are tied to a specific version of your code. Older findings stay visible with a clock icon until you run that scan again.

Can I just ignore the warning?

Only if the data is meant to be public. Lovable says ignoring "should be a deliberate decision". Bolt says its RLS Policy Always True warning is acceptable only if you're comfortable with every visitor being able to change or delete that data.

Does asking the AI in chat to check my security work?

It costs you. In Lovable, a chat security review consumes credits and doesn't update the scan results. In Bolt, prompting an audit decreases your token balance, while the Run security audit button in the Publish menu doesn't use tokens.

My app shows empty lists after the security fix. What happened?

The fix may have turned on Row Level Security without adding a policy. Supabase returns no rows through the API until you create policies. Add a policy that lets each user read their own rows instead of turning RLS off.

Does a clean scan mean my app is safe?

Not on its own. Lovable says the scanner "cannot catch every possible risk". Test with a second account too.

Sources