Vibe coding means someone describes in plain language what an app should do, and an AI writes the code. With tools such as Lovable, Bolt or Replit, apps that once took a development team weeks are built in a few hours. The problem: what works is far from secure. The security company Escape examined around 5,600 publicly reachable apps built on such platforms and found more than 2,000 vulnerabilities and over 400 exposed access keys.
Which gaps occur most often?
- Open databases: the most common cause in the Escape study was misconfigured access rules in Supabase. Anyone who knows the address can then read or change data.
- Keys in the browser: API keys for payment services, email or AI sit in code that every visitor can see.
- Permissions only in the front end: the app hides buttons but does not check on the server whether someone may perform the action.
- No input validation: forms accept anything, including malicious code.
- Outdated packages: libraries with known vulnerabilities are not updated.
- No operation: there are no backups, no monitoring and nobody installing updates.
Why does this happen so often?
The AI builds what is requested and optimises for the app to run. Security is rarely requested explicitly, and the person describing the app is usually not a developer and does not know what to ask for. Many of these tools start as an internal prototype and are then used with real customer data without anyone having reviewed the code.
What should you check before using it?
- What data does the tool process? Does it include personal data or trade secrets?
- Who can log in, and who may see and change what? Is this checked on the server?
- Are the database access rules set so that nobody gets to data without permission?
- Are keys and passwords stored securely on the server instead of in the code?
- Who installs updates, who makes backups, and who notices when something fails?
- Who owns the code, and can someone else continue developing it?
How does a prototype become a secure tool?
A self-built tool does not have to be thrown away. Often it is enough to close the critical points specifically: set access rules, move keys to the server, check permissions on the server side, update dependencies and set up proper operation. That is exactly what we do in the vibe code check. More on our Web Apps & MVP page.
Sources
- Escape: Methodology: 2k+ Vulnerabilities in Vibe-Coded Apps
- Security Boulevard: How we discovered over 2k high-impact vulnerabilities (October 2025)
- Computerweekly: Vibe coding: opportunities, risks and strategies (German)
