AI-powered app builders have made it possible for anyone to create polished applications without writing code, but the invisible infrastructure behind those apps is where real problems hide. A researcher scanning apps built on Lovable found roughly 170 with their databases completely readable by anyone, while other AI-built applications have leaked millions of API keys and exposed personal photos, according to security researchers. The gap between what looks finished on screen and what actually keeps user data safe is where most vibe-coded apps fail.

Why Do AI-Built Apps Keep Leaking User Data?

The most common security failure in AI-generated applications stems from a single misconfiguration: databases left wide open to the public internet. When an AI tool builds an app, it typically connects to a database service like Supabase or Firebase using a public key, which is intentional and necessary. What keeps data safe is a set of rules that restrict who can read and write information. In Supabase, these rules are called Row-Level Security (RLS). If they're switched off or poorly configured, anyone with basic technical knowledge can copy that public key, open their browser's developer tools, and read every user's name, email, address, and private messages.

This isn't theoretical. In 2025, a security researcher discovered approximately 170 Lovable-built apps with completely exposed databases. The AI social app Moltbook leaked 1.5 million API keys the same way, identified by the security firm Wiz. The Tea app left a storage bucket open, allowing roughly 72,000 images, including selfies and ID photos, to be accessed by anyone. Each incident followed the same pattern: Row-Level Security was either disabled or misconfigured.

What Are the Real Risks When You Cross from Personal to Public?

The stakes change dramatically the moment someone other than you can log in and share their data. A tiny app with ten real users and their personal information carries the same legal and security exposure as a massive platform. The difference between a personal tool and a public application isn't about scale; it's about whether someone else's data or money is flowing through it.

Beyond database exposure, AI tools frequently paste secret API keys directly into the code that runs in users' browsers. Keys for payment systems like Stripe, AI providers like OpenAI, or admin-level database access are essentially passwords. If they end up in browser-visible code, every visitor has them. Bots scan the public internet constantly for exactly these kinds of exposed secrets. One developer on Hacker News watched a leaked key accumulate $300 in unauthorized usage within two days. Security firm Escape.tech scanned thousands of vibe-coded apps and found hundreds with exposed secrets embedded in their code.

How to Secure Your AI-Built App Before Launch

• Database Access Control: Ask your AI tool directly: "Is Row-Level Security turned on for every table in my database, and does every rule restrict each user to only their own rows?" Then test it yourself by logging out and trying to load data. If anything appears, the door is open. The trap is that Row-Level Security can be switched on but still allow everyone to read everything, so ask to see the actual rules, not just whether one exists.
• Secret Key Management: Search your entire project, including code that runs in browsers, for any secret keys or passwords starting with "sk-", "sk_live_", "service_role", or any API key. Move them to the server side immediately and regenerate every exposed key in its own dashboard, since keys that have been public are compromised even after you move them.
• Permission Checks on the Server: For every protected page and admin action, verify that permission is checked on the server, not just hidden in the design. Test this by logging in as yourself, then changing the ID in the URL to a different one. If you can see someone else's data, that's a critical hole. One founder launched a sales tool with AI and zero hand-written code, only to have users bypass the paywall by editing a single value in their browser within 72 hours, running up massive API bills and filling the database with junk.
• Spending Caps and Billing Alerts: Set a hard spending cap in your build tool today, around one and a half times what you expect to spend. On every paid service behind the app, such as OpenAI or Google, set a usage cap and a billing alert. If you normally spend $5 a day, set an alert at $50. One user posted a $607 Replit bill from just a few days of building, and bots can hammer unprotected services all night on your card.

The platform Base44 itself had a vulnerability that let anyone create a verified account on a private company app, discovered by Wiz and patched within a day, demonstrating that even the tools building these apps can miss critical security checks.

The core insight is that software has been a profession for fifty years not because developers were guarding easy bits, but because the invisible infrastructure is genuinely complex. AI is brilliant at the part you can see on screen and quiet about the part you can't, which is a lovely combination right up until other people start relying on your application. The good news is that most of these traps can be checked in about the time it takes to make a coffee, and the questions to ask are straightforward enough to pose directly to the same AI tool that built the app.

The line that actually matters isn't whether your app is big; it's whether someone else's data or money is running through it. A single question changes everything: who is actually going to use this? If the answer is just you on your own machine, you can skip nearly all of these checks and enjoy building. But the moment strangers can log in and hand over their email, photos, or payment information, every check becomes essential.