cd /news/ai-safety/lovable-security-what-our-independen… · home › topics › ai-safety › article
[ARTICLE · art-164144] src=getastra.com ↗ pub= topic=ai-safety verified=true sentiment=↓ negative

Lovable Security: What Our Independent Pentest Found

An independent Astra autonomous pentest of an app generated by Lovable found 27 confirmed, exploitable vulnerabilities — 5 High, 18 Medium and 4 Low, with no Critical — out of 137 total findings across the four AI coding platforms tested (Lovable, Emergent, Replit and Base44). The High findings centered on broken access control, including 811 user profiles readable by any authenticated account, exposed role and admin data, an unauthorized Supabase channel and an MFA bypass where a password alone sufficed; every raw Lovable finding passed vetting with no rejections. The study, which gave all four platforms an identical prompt with no security instructions, concludes the risk sits in the generated application and its Supabase backend rather than Lovable's own platform, and recommends enforcing row-level security in the database and specifying exact thresholds such as a maximum of 5 failed logins per account per 15 minutes with a 429 response.

by read3 min views1 publishedNov 4, 2026
Lovable Security: What Our Independent Pentest Found
Image: Getastra (auto-discovered)

Lovable security came under the spotlight when we gave it the same build prompt as three other AI coding platforms, let it generate a complete application, and put the result through Astra’s autonomous pentest. The app worked, and it also shipped with 27 confirmed, exploitable vulnerabilities, part of 137 across the four apps in our vibe coding security study.

Lovable was nearing 8 million users by late 2025, so a lot of people are shipping builds like the one we tested, and what those builds carry into production deserves an answer backed by evidence.

Is Lovable safe to use? #

The short answer is that the risk sits in your app rather than theirs, and the question splits in two. Lovable’s own platform, its editor and infrastructure, is one thing, and we didn’t test it. What gets generated into your application, including the Supabase backend it wires up for you, is another, and that’s what we tested.

Asking how secure apps built with Lovable are really means asking what the generator does when your prompt says nothing about security, and our answer comes from exploiting one.

What we found in the Lovable-built app #

Lovable received the identical prompt as Emergent, Replit, and Base44, with no advance notice and no vendor relationship affecting the results.

Two independent pentest bots attacked each app, one mapping the app and building attack chains, the other going in cold like an unbriefed attacker. A validator agent re-exploited every candidate finding, and a human security engineer reviewed whatever remained. 137 findings across the four apps survived that process.

Lovable’s share was 27, and every raw finding it produced passed vetting without a single rejection. The breakdown was 5 High, 18 Medium, and 4 Low, with no Critical findings.

The High findings centered on broken access control, including 811 user profiles readable by any authenticated account, exposed role and admin data, an unauthorized Supabase channel, and an MFA bypass where the password alone was enough. Session tokens that stayed valid after logout, weak cookie flags, and user enumeration rounded out the list.

Why these Lovable security issues show up #

The generator builds what the prompt asks for. Ours asked for a working app with named features, and the findings landed where the security asks were general or missing. Most of what we confirmed comes down to configuration and data-layer defaults rather than coding mistakes, such as a missing header or a permissive origin policy.

On a Supabase-backed build, the single highest-value check is Supabaserow-levell security.

The hardened prompt in our report tells the generator to implement row-level security or an equivalent so users can only see their own data by default, because 811 profiles readable by any logged-in account is what a gap at that layer looks like, whether RLS is off or the policies skip a table.

How to harden a Lovable app before you ship #

Be specific in the prompt, since exact thresholds beat “make it secure.” Ask for a maximum of 5 failed logins per account per 15 minutes with a 429 after, rather than a secure login.

Enforce access control in the database, not just the interface. A UI that hides admin buttons protects nothing when the table behind it answers every query.

Then run the 10-minute check on the running app. Log in eight times with the wrong password and expect a 429 around attempt six, open DevTools and look for a Content-Security-Policy header on any response, and reset a password with a fake and a real email, confirming the response, wording, and timing match.

Final thoughts #

Lovable gets you to a working app fast, and that speed is the point of it. The same nine weak points appeared across all four apps we tested, so the Lovable security risks here say more about generated code in general than about one vendor.

Treat the prompt as a spec and the database as where access control lives, and you close most of that shared ground.

For a real app rather than a demo build, Astra’s autonomous pentest runs the same process against your running application. The full data is in the Vibe Coding Security Risks Study.

── more in #ai-safety 4 stories · sorted by recency
── more on @lovable 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/lovable-security-wha…] indexed:0 read:3min 2026-11-04 · —