If You Vibe-Coded an App, Assume the Database Is Public

Security researchers have been scanning apps built with no-code AI tools, and the results should change how you treat anything you vibe-coded. A scan by the security firm RedAccess of roughly 380,000 publicly reachable apps built on platforms like Lovable, Base44, and Replit found around 5,000 actively leaking sensitive data: API keys, customer records, in some cases payment or health data. Earlier testing of thousands of vibe-coded apps had already found large numbers of vulnerabilities. If you built a customer-facing app by describing it to an AI and never had anyone check the security, the safe assumption this weekend is that your database is reachable from the open internet until you prove otherwise.

The tool that let you skip the developer also let you skip the security review. That is the whole risk in one sentence.

Why these apps leak

The leaks are not exotic. They come from the boring default that makes vibe coding feel magic: the app is wired up to read and write data with as little friction as possible, and “as little friction as possible” usually means the data is open unless someone closed it. A developer building the same app would have set up access rules as a matter of habit. The AI generated a working app and left those rules to you, and nobody told you they were your job.

The most common single cause researchers point to is database access left in a public state, where anyone who finds the address can read or write the records. The app looks finished and works perfectly for you. It also works perfectly for anyone else who knocks.

The case worth knowing

Lovable is a useful example because it was documented in detail. Between February and April 2026 the platform had a flaw where project links could expose other projects’ data and code. It shipped access checks for new projects but left a window where existing projects stayed open (The Next Web). The lesson is not that Lovable is uniquely unsafe; it is that the platform will not necessarily protect you by default, and that the gap between a problem being found and being fixed can run for weeks. During that window, your data is your responsibility, not the vendor’s.

The encouraging half of the story is that the defenders moved too. In May 2026 several platforms shipped built-in security scanners and access-control tools aimed at exactly this problem. They only help if you turn them on.

The check is cheaper than the breach

If you are an EU or EU-serving business and one of these apps leaks personal data, you are into breach-notification territory and the duties that come with it. That is the real cost, and it is why the thirty-minute check in the box above is worth doing before the weekend is out, not after the first odd email from a customer.

You do not need to be technical to do most of it. List what you built. Open each app’s data settings and confirm a login is required to read records. Run the platform’s scanner. Rotate any key that was ever visible. Flag anything touching payments or health data for a proper review.

This week

Spend thirty minutes on the check above, in order, starting with the app that holds the most customer data. If you find an open database, closing it is usually a single setting, and rotating an exposed key is a few minutes. If you cannot tell whether your data is private, that uncertainty is the finding: book a one-off review rather than hoping. The point of vibe coding was to ship without a developer. The cost of that is that the security review nobody did is now yours to run, and it is a far smaller job than the breach it prevents.