Your vibe coded app works. You clicked through every screen, ran a signup, maybe showed a few beta users, and nothing broke. That's not the same question as whether it's ready for real users with real data. Taking a vibe coded app to production means someone has checked what a working demo never surfaces: whether a stranger can read your Stripe secret key straight out of the JavaScript bundle, whether row-level security is actually switched on for every table, whether the admin panel is gated by anything more than an unlisted URL.
Wiz Research found that one in 5 organizations building on vibe-coding platforms are inadvertently exposing themselves to risk, and its researchers grouped the recurring failures into four patterns: authentication logic that runs entirely in the browser, API keys and secrets shipped in client-side code, database access left open through missing or overly permissive row-level security, and internal tools that were never meant to be public getting deployed publicly anyway. One incident Wiz documented involved a vibe-coded enterprise game that leaked all of its users' personally identifiable information and IP addresses. Wiz ended up partnering with Lovable directly on remediation guidance, which says something about how common the pattern got.
Escape.tech's scan of 1,400 vibe-coded applications turned up 2,038 highly critical vulnerabilities, 400-plus leaked secrets, and 175 separate instances of exposed personally identifiable information, including bank account data. That pattern isn't a knock on any one tool. An AI assistant optimizes for whether the feature works, not for whether someone who shouldn't see the data can still reach it, unless something specifically checks for that second thing.
Why a working prototype isn't a production-ready app
A vibe-coding platform builds fast because it makes decisions for you: what the data model looks like, how auth is wired, which tables get exposed to the frontend. Most of those decisions are reasonable defaults. Some assume you'll go back and lock things down before real users show up, and if nobody told you that step exists, you won't take it.
The clearest example is row-level security on a Postgres-backed platform like Lovable's Supabase integration. RLS decides which rows a given user can read or write. Skip it, or configure it loosely, and every row in that table is fair game for anyone who can reach the API, not just the user it belongs to. CVE-2025-48757, disclosed by independent security researcher Matt Palmer with a CVSS base score of 8.26, is this failure mode at scale: missing or misconfigured RLS on Lovable-built apps exposing personally identifiable information from users tables (names, email addresses), API keys and access tokens for third-party services, and financial data including transaction and subscription details. Palmer's follow-up statement on the scope of that scan put a number on how widespread it was: 303 vulnerable endpoints across 170 projects, roughly 10.3% of the 1,645 applications he analyzed. He found the issue on March 20, 2025, notified Lovable the next day, got acknowledgment on March 24, and the vendor disclosed publicly on April 15, ahead of his own public writeup on May 29.
None of this means Lovable is unsafe to build on today. A working demo and a checked one are two different things, and by default nothing checks the second one for you. How AI tools get permissioned and governed across an engineering org more broadly is the subject of HighCircl's AI in the engineering workflow: tools, permissions and policy hub. A vibe-coded prototype is just the earliest, highest-stakes version of that same question.
How to check if your vibe coded app is secure
1. Audit row-level security on every table
Open every table your app touches and confirm RLS is enabled, not just present. Lovable's own security documentation is explicit that RLS controls who can read or modify individual rows and recommends enabling it on every sensitive table before publishing. This is the single most common failure mode in the vulnerability reports above: a table sitting open to anyone who can query it because RLS was never turned on, or was turned on with a policy loose enough to defeat the purpose.
2. Find and rotate any secrets shipped to the frontend
Open your browser's dev tools, check the network tab and the compiled JS bundle, and search for anything that looks like an API key, a database connection string, or a third-party token. Lovable's own guidance states plainly that secrets stored in frontend code are visible to users and should be considered compromised the moment they ship, and that sensitive values belong in the platform's dedicated secrets manager, not in code sent to a browser. If you find one, don't just delete it. Rotate it at the provider, because anyone who loaded your app before you noticed already has the old value.
3. Confirm auth and authorization decisions run server-side
A user who opens dev tools can edit localStorage and flip a client-side flag from role: user to role: admin to see what happens. If your app's admin check lives in the browser, that's exactly what happens: they get in. Lovable's documentation is direct on this point too: all authentication decisions must happen server-side, and a function running on the server is still callable by any client, so server-side execution alone doesn't make an operation private unless that function itself checks who's calling it. Test this by trying to break your own app as a logged-out or low-privilege user before a real one does.
4. Run the platform's own security scan, then an independent one
Lovable runs a basic automated scan in roughly 10-15 seconds before publishing and offers a deeper AI-powered scan, on demand, that takes about 3 minutes, according to its security page. Treat that as a floor, not a ceiling. A platform-native scan is tuned to catch the mistakes that platform's users make most often; it isn't a substitute for someone outside the tool looking at your specific app with fresh eyes. That second pass follows the same logic as a security-specific code review checklist for any other codebase: automated scanning catches the mechanical patterns, and a human pass catches the judgment calls a scanner can't make. This is one of the places bringing in a fractional CTO pays for itself, an independent technical read on exactly this app, not a generic checklist.
5. Map findings to OWASP's access-control category to prioritize
If you come out of steps 1-4 with a list of problems and no idea what to fix first, start with anything that's a broken access control issue. OWASP ranked broken access control first in its 2021 Top 10, up from fifth in the prior list, after 94% of the applications in its dataset were tested for some form of it, with an average incidence rate of 3.81% across more than 318,000 occurrences. Missing RLS, client-side auth checks, and exposed admin routes are all broken access control. Fix those first: they're the most common category and the one most directly tied to the incidents above.
Rebuild or refactor: how to decide
Not every insecure vibe coded app needs to be thrown out. The decision comes down to where the problems actually live.
If the data model is sound, the core flows make sense, and what you found in the audit above is contained to security and structure fixes, refactor. Lock down RLS, move secrets to the platform's secrets manager, move auth checks server-side, and keep the product you have. Most of what a vibe-coding platform builds is genuinely fine at this level; it's the access-control layer that tends to lag.
Rebuild when the foundation itself is wrong: a data model that can't support the features you actually need next, an architecture that made sense for a demo but not for real traffic, or security holes that turn out to be systemic rather than a short list of fixable settings. If the audit keeps surfacing new instances of the same problem across every table and every route, that's not five bugs. That's a pattern, and patching five instances of it doesn't fix the sixth one nobody's found yet.
Either path is a technical judgment call, not a business one, which is why it's worth getting an outsider's read before committing engineering time to either direction. Guessing wrong here, in either direction, costs more than the assessment would have.
How to hand off a vibe coded app to an engineering team
1. Package the security findings as a fix list, not just a bug list
A bug tracker entry says "signup form breaks on Safari." A fix list says "the orders table has no RLS policy; any authenticated user can read every order in the database." An engineer walking in cold needs to know what's broken, why it matters, and what data or access is exposed if it stays broken. Hand over the first kind of list and the security issues get triaged as low-priority polish. Hand over the second kind and they get fixed first.
2. Transfer platform, hosting, and secrets-manager ownership, not just a GitHub link
A repository isn't the whole app. Whoever takes this over needs admin access to the vibe-coding platform account itself, the hosting provider, the database, and the secrets manager, not read access to a code export. If any of those live under your personal login, that's a dependency on you personally that outlives the handover you're trying to complete.
3. Document what the AI tool built implicitly
There's no design doc, because nobody wrote one. The AI tool made decisions about the auth flow, the data model, and the RLS policies as it went, and those decisions live in the code, not in a document an engineer can read first. Write down, even briefly, how auth actually works, what each table is for, and which RLS policies exist and why. An hour of your time here saves a new engineer days of reverse-engineering the same thing from scratch.
4. Decide the engagement shape before the engineer starts
Audit only, refactor, or rebuild: pick one before the work begins, not after the first invoice. An engineer who thinks they're doing a quick security pass and discovers mid-engagement that the whole data model needs rework is now negotiating scope instead of doing the work. This is also the point where a short, structured technical assessment, the kind covered in a founder's guide to technical due diligence, earns its keep even outside a fundraising context: it forces the rebuild-vs-refactor call onto paper before it happens by accident mid-sprint.
What EU founders should check for GDPR exposure
If your vibe coded app stores personal data, an RLS misconfiguration is a security bug first. Whether it's also something more serious depends on what happened next: if personal data was accessed by someone without authorization, that's a personal data breach under GDPR, and Article 33's 72-hour notification duty to the supervisory authority can apply.
Article 33 requires the controller to notify the supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of" a personal data breach, unless it's unlikely to result in a risk to individuals. Seventy-two hours isn't a lot of runway if you don't learn about the exposure until a researcher emails you or a customer notices something wrong. It's considerably less runway if you don't know the obligation exists until after the clock has already started.
This is the exposure pattern in the incidents above: a users table without proper RLS, readable by anyone who can query it, containing names, emails, and sometimes financial details. If your app has EU users and stores anything that identifies them, the security audit in the how-to section above isn't optional hardening. It's what tells you whether Article 33 applies to you before you find out the hard way. HighCircl's guide to EU engineering hiring compliance covers the contracting side of this; the technical side starts with knowing whether your RLS policies actually match what you think they do. HighCircl's own engineering network runs GDPR-native, EU member states only, for what that's worth as a reference point for the constraint your app needs to satisfy.
FAQ
Is Lovable itself secure, or is it the apps built on it?
Both statements can be true at once, and they usually are. Lovable's own documentation lays out real guidance: enable RLS, keep secrets out of frontend code, run auth checks server-side, and the platform runs automated scans before publishing plus deeper on-demand scans, SAML/OIDC and SCIM for enterprise customers, and regional hosting with no cross-region data movement by default. None of that helps if the guidance wasn't followed on the specific app you built. The platform ships the tools; whether a given app used them correctly is a separate question, and it's the one that determines whether your data is exposed.
Does the 2025 Lovable vulnerability still affect apps built today?
CVE-2025-48757 was a pattern, missing or misconfigured RLS, not a single bug in Lovable's code that got patched once and closed forever. Palmer's disclosure timeline shows the vendor acknowledged the report within days and disclosed publicly within weeks, but RLS is a per-app, per-table configuration. An app built today can still ship with RLS off or loosely configured, because that's a decision made in each project, not a platform-wide default that got permanently fixed. That's why the RLS audit above still matters regardless of when your app was built.
Do investors care if an MVP was vibe coded?
The relevant question isn't the tool, it's whether the app can survive scrutiny. A vibe-coded MVP that's had its RLS policies audited, its secrets rotated out of the frontend, and its auth checks moved server-side reads the same as any other codebase in a technical review. One that hasn't had any of that done is the one that raises questions once someone takes a quick look, regardless of what built it.
Can a team keep using Lovable, Bolt, or Replit after an engineer takes over, or does it have to become hand-written code?
That depends on the audit and the rebuild-vs-refactor decision above, not on a blanket rule. If the foundation is sound and the fixes are contained to security and configuration, an engineer can keep building on the same platform, working directly in its generated codebase like they would in any other. If the decision comes out as a rebuild, the platform's role usually ends there, though nothing stops a team from prototyping a future feature there again later.