Your Lovable MVP works. Here's what will leak

Lovable delivers something that seemed impossible not long ago: you describe a product and, in one afternoon, you have screens, login and a working database. I think that's great for validating an idea. The trouble starts when we confuse “it works” with “it can go live with real people's data.”

On February 27, 2026, The Register reported, in a story by Connor Jones, the case of an app hosted on Lovable and listed in the platform's showcase. Researcher Taimur Khan found 16 flaws, six of them critical. The result: 18,697 user records exposed.

What happened to the app in Lovable's showcase

The app had more than 100,000 views and about 400 upvotes when Khan started his analysis. It was used by teachers and students, including people from UC Berkeley and UC Davis. Of the exposed records, 14,928 were unique emails, 4,538 were student accounts and 870 users had full personal data in plain view.

The flaws weren't sophisticated:

• No row-level access rules in the database. The Supabase backend had no row-level security and no role-based control. Anyone who reached the database saw everything.
• Login logic flipped. An auth function blocked logged-in users and let logged-out ones through. In Khan's words: “The guard blocks the people it should allow and allows the people it should block.”
• Admin powers for anyone. A logged-out visitor could see every user, send mass emails, delete accounts and change grades.

Lovable said it takes this kind of finding “extremely seriously” and acted within minutes of receiving the formal report. The company's CISO, Igor Andriushchenko, said every project gets a free scan before publishing, but applying the recommendations is the user's call. The company also said the project included code not generated by Lovable and that the vulnerable database wasn't hosted by Lovable.

Why this isn't just a Lovable problem

The same report cites Veracode: 45% of AI-generated code contained security flaws. In other words, the risk isn't in one specific tool. It's in how AI writes code: it delivers the happy path, the one where the user does exactly what you imagined.

Security is the unhappy path. It's what happens when someone opens the app logged out, changes a number in the URL or calls the API directly. AI doesn't test that on its own. And the screen shows nothing wrong, because the screen works.

Security checklist before you launch your MVP

This is the list I'd run on any MVP built with Lovable, Bolt, Replit or similar before opening it to real users. It doesn't replace a full review, but it catches the kind of flaw in the case above.

Database

1. Row-level security on for every table. In Supabase, a table without RLS is open to anyone with the public key, which lives in your front end.
2. Policies written per role. Students see their own data. Teachers see their class. Admins see everything. Each rule has to exist in the database, not just on screen.
3. Test with two users. Create two accounts and, with the second, try to read or edit the first one's data.

Authentication

4. Open the app in an incognito window. Visit every route logged out. Nothing private should load.
5. Read the route guard function. Check that the condition points the right way. The case above shows one flipped negation is enough.
6. Admin actions checked on the server. Hiding the button protects nothing. The API has to reject the request.

Keys and secrets

7. No secret keys in the front end. Database service keys, payment keys and email keys stay on the server.
8. Environment variables reviewed. Check what goes to the browser and what stays on the server.

Data and operations

9. Collect only what you need. Every extra personal field is one more field to leak.
10. Rate limits on sends and requests. A route that fires emails with no limit becomes a spam tool.
11. A contact channel for people who find flaws. Khan says his first report was closed without a reply. Have a clear email address and respond.
12. Run the platform's scan and apply what it flags. It exists. Ignoring the recommendation is the cheapest flaw to avoid.

What this means for you

If your MVP was built with one of these tools, it's probably closer to launch than a project starting from scratch. That's good. Just don't skip the step AI doesn't do on its own, part of the 30% missing from your MVP.

At the Studio, we use Claude Code and Figma for design and build, and every system ships with an AI agent that runs daily, flags issues, suggests improvements and checks that the data makes sense. In the discovery for an inherited MVP, we review login and permissions, exposed keys, database access rules and dependencies before we talk price.

After discovery, you get a fixed price and a deadline written into the contract to take the MVP to the point where it can handle real users. If your Lovable app already works and you want to be sure it won't leak in the first month, the Studio's project rescue was built for that moment.