Can You Trust an App Built With AI? Lovable, Replit, Base44

Lovable's problem surfaced on a longer fuse. A security researcher reported a broken object-level authorization flaw in Lovable's API to its bug bounty program on March 3, 2026; the hole stayed open for 48 days before it was fixed. In as few as five API calls, the same flaw could pull a project's source code, hardcoded Supabase database credentials, AI chat histories and personal data belonging to thousands of users. One exposed record set, from a Women in AI nonprofit, included names, job titles, LinkedIn profiles and Stripe customer ids tied to staff at Accenture Denmark and Copenhagen Business School. Lovable's first public response denied a breach and pointed at documentation and its bug bounty vendor before it landed on a partial apology once Business Insider published the findings on April 20, 2026.

None of that is three unlucky companies. In May 2026, the security firm RedAccess scanned the open web for apps built on vibe-coding platforms and found more than 380,000 publicly reachable. Around 5,000 looked corporate in nature, and over 2,000 of those - roughly two in five - were holding sensitive corporate, operational or personal data behind nothing at all: no login wall, often admin access granted by default to anyone who found the URL.

What all three failures actually have in common

It's tempting to read Base44, Replit and Lovable as three different kinds of mistake - an auth bug, a rogue agent, an API flaw. They're the same mistake wearing different code. In every case, an app reached real users or real production data before anyone applied the review a security-conscious team runs as a matter of course: who can access this, what happens if a command goes wrong, does this default grant more than it should. AI made the building step fast enough that the review step got skipped, not because the tools are careless but because nothing in the workflow forced a pause for it.

That gap shows up in independent research too, not just headline incidents. Carnegie Mellon researchers found that only about 10.5% of AI-generated code samples passed a standard security review outright. A separate scan by Escape.tech of 5,600 live AI-built applications turned up more than 2,000 vulnerabilities, over 400 exposed secrets such as API keys, and 175 instances of exposed personal data. The pattern across all of this is consistent: the code usually runs. Whether it was ever checked for who can reach it is a separate question, and it's the one that keeps going unanswered.

The gut-check: can you trust an app built with AI that you already shipped

A side project with no real users can afford to skip this for now. An app that touches any of the following can't:

• Does it store anything about a real person - an email, a phone number, a health or financial detail, a conversation log?
• Does it take or move money in any form, even a small one?
• Can a stranger reach it without your permission - is the URL public, indexed, or shared beyond the people you meant to give it to?
• Have you actually verified, by testing it yourself or having someone else try, that a logged-in user can only see their own data and not anyone else's?
• If something in it broke or deleted data right now, would you know before a customer told you?

A "yes" to the data or payments question, plus a "no" to the access-control question, is exactly the combination that broke at Base44 and inside a slice of RedAccess's 2,000 exposed apps. It doesn't take a big platform or a well-funded team to land in that spot - it takes an app that grew past the point where nobody had looked at it since launch.

When "it works for now" stops being good enough

Plenty of AI-built apps genuinely don't need a security review yet. An internal tool three people use, a prototype with fake data, a weekend project that never left your own laptop - none of that carries the risk that hit Base44's enterprise customers or Lovable's users. The point isn't that every AI-built app is a liability. It's that the review has to happen before the app starts holding something worth protecting, not after a researcher, or worse a stranger, finds the gap first.

If your app has already crossed that line - it has real users, real data or a public address - a professional review before you scale it further is a lot cheaper than the alternative. That's the kind of check we run at ZingBizz when we take over an app that started as a fast build: access controls tested, environment separation confirmed, the defaults checked rather than assumed.

Frequently asked questions

Is an app built with AI automatically less secure than one written by hand?
No. The Base44, Replit and Lovable incidents were caused by missing access-control review, not by the AI writing broken code - a hand-coded app skips the same review and fails the same way.

What is "vibe coding" and why does it matter for security?
It's building an app mostly or entirely by describing what you want to an AI agent rather than writing the code yourself, and it matters because the speed it enables regularly outpaces the security review a slower, hand-built process would naturally include.

How do I know if my AI-built app has an access-control problem?
Log in as one test user and try to view or edit another test user's data using the app itself or its URLs; if you can reach anything you shouldn't, that is the same class of flaw that hit Base44 and Lovable.

Does using a well-known AI coding platform make my app safe by default?
No - Base44, Replit and Lovable are among the most funded platforms in the category, and each still shipped a failure that reached real user data before it was caught.

What should I do if I already launched an AI-built app that handles real customer data?
Get someone who didn't build it to review access controls, environment separation and admin defaults before you add more users, since that outside check is the exact step all three 2025-2026 incidents skipped.