Bolt.new vs Lovable vs Cursor: Which Produces the Most Secure Code?
We compared the security output of three leading AI coding tools. Here's what each one gets right, what it gets wrong, and which one ships the most vulnerabilities.
By Paula C · Kraftwire Software
· 10 min readThe Question Every Vibe Coder Asks
If you're building with AI tools, you've probably wondered: **which one writes the most secure code?**
Bolt.new, Lovable, and Cursor are the three most popular AI coding platforms in 2026. Each takes a fundamentally different approach to code generation - and each introduces different security risks.
We analyzed the security patterns produced by all three tools across common app-building scenarios: authentication flows, database CRUD, API integrations, and form handling. Here's what we found.
How Each Tool Works
Before comparing security output, it helps to understand how each tool generates code:
Lovable
Lovable generates **full-stack React + Supabase applications** from natural language prompts. You describe what you want, and Lovable produces a complete app with frontend, database schema, RLS policies, and authentication - all wired together.
**Security implication:** Because Lovable generates the entire stack, security issues tend to be systemic. If RLS is misconfigured, it affects every table. If a service-role key leaks, the entire database is exposed.
Bolt.new
Bolt.new runs a **full development environment in the browser** via WebContainers. It generates frontend and backend code from prompts, with instant preview and deployment.
**Security implication:** Bolt generates working code fast, but tends to prioritize functionality over security configuration. Missing headers, open CORS, and exposed API keys are common patterns.
Cursor
Cursor is an **AI-powered code editor** that augments your existing development workflow. It generates code within your project context using autocomplete, inline edits, and multi-file generation.
**Security implication:** Because Cursor works within your codebase, security depends heavily on what you ask for. It rarely adds security measures proactively - if you don't ask for input validation, you won't get it.
Category 1: Secret Management
Lovable
**Risk level: High**
Lovable's most critical vulnerability - [CVE-2025-48757](/blog/cve-2025-48757-lovable) - involved Supabase service-role keys leaking into client-side JavaScript. While this specific issue has been addressed, the pattern of environment variable handling remains a concern. `VITE_` prefixed variables are bundled into the frontend, and AI-generated code doesn't always distinguish between safe and dangerous prefixes.
**Common findings:**
Service-role keys in client bundles (critical)
`VITE_` prefix used for backend-only secrets
API keys hardcoded in component files
Bolt.new
**Risk level: High**
Bolt.new apps frequently bundle third-party API keys directly into frontend JavaScript. When you ask Bolt to "add Stripe payments" or "integrate OpenAI," the generated code often puts the secret key in client-side code rather than creating a server-side proxy.
**Common findings:**
Stripe secret keys in client code
OpenAI API keys in fetch headers
Firebase admin credentials in frontend bundles
Cursor
**Risk level: Medium**
Cursor generates secrets inline less frequently than full-stack generators because it works within existing project structures. However, when generating new integrations, it may suggest hardcoding API keys directly in source files.
**Common findings:**
API keys in utility files
Secrets committed to git via `.env` files
Missing `.gitignore` entries for credential files
**Winner: Cursor** - its incremental approach means secrets are less likely to end up in client bundles, though it's not immune.
Category 2: Database Security (RLS)
Lovable
**Risk level: Medium-High**
Lovable automatically generates Supabase RLS policies, which is a significant advantage. However, the generated policies are often too permissive - using `USING (true)` clauses that allow any authenticated user to read all data, or missing tables entirely.
**Common findings:**
`USING (true)` on sensitive tables
Missing RLS on newly created tables
No RLS policies for DELETE operations
Overly broad INSERT policies
Bolt.new
**Risk level: High**
Bolt.new doesn't generate Supabase projects by default - when it does integrate with databases, security rules are frequently missing entirely. Firebase projects generated by Bolt often ship with open Firestore rules.
**Common findings:**
No RLS or security rules configured
Open Firestore `read: true, write: true` rules
Database connections using admin/root credentials
Cursor
**Risk level: Variable**
Cursor generates whatever you ask for. If you prompt "create a users table with RLS," you'll get RLS. If you prompt "create a users table," you probably won't. Security is entirely dependent on the developer's awareness.
**Common findings:**
RLS only present when explicitly requested
Generated policies may have logic errors
No proactive security suggestions
**Winner: Lovable** - despite its issues, it's the only tool that generates RLS policies by default. The policies need review, but having them at all is better than nothing.
Category 3: Authentication
Lovable
**Risk level: Medium**
Lovable generates complete authentication flows with Supabase Auth. The risk areas are auto-confirm email signups (allowing unverified accounts), client-side admin checks, and missing session expiry configuration.
**Common findings:**
Auto-confirm email enabled by default
Admin role checked in localStorage (bypassable)
Missing session timeout configuration
Bolt.new
**Risk level: High**
Bolt.new apps often implement authentication with significant gaps. Login forms may work visually but lack brute-force protection, session management, or proper token storage.
**Common findings:**
No rate limiting on login endpoints
JWTs stored in localStorage (XSS-vulnerable)
Missing email verification
Password reset flows that leak tokens in URLs
Cursor
**Risk level: Medium**
Cursor generates authentication code that reflects your prompt. If you ask for "secure authentication with email verification, rate limiting, and httpOnly cookies," you'll get something close. If you ask for "add login," you'll get a basic form.
**Common findings:**
Security depends entirely on prompt specificity
May suggest localStorage for token storage
Rarely adds rate limiting unprompted
**Winner: Lovable** - again, having a complete auth flow by default (even with issues) beats having gaps.
Category 4: XSS & Injection
Lovable
**Risk level: Low-Medium**
Lovable generates React code, which escapes content by default. XSS risks emerge when `dangerouslySetInnerHTML` is used for rendering CMS content, markdown, or user-generated HTML.
Bolt.new
**Risk level: Medium**
Similar React-based XSS profile. Bolt is slightly more likely to generate `dangerouslySetInnerHTML` for dynamic content rendering and URL parameter injection.
Cursor
**Risk level: Medium**
Cursor may generate XSS-vulnerable patterns depending on context. It's more likely to suggest `eval()` or `Function()` for dynamic code execution since it's optimized for developer productivity.
**Winner: Tie (Lovable and Bolt)** - all three use React's default escaping, with similar edge case risks.
Category 5: Security Headers & Configuration
Lovable
**Risk level: Medium**
Lovable apps deploy on Lovable's infrastructure, which provides some default headers. However, Content-Security-Policy, HSTS with long max-age, and Permissions-Policy are typically missing.
Bolt.new
**Risk level: High**
Bolt.new apps consistently lack security headers. CSP, X-Frame-Options, HSTS, and CORS configuration are almost never generated.
Cursor
**Risk level: Variable**
Cursor generates headers when asked. Most developers don't think to ask.
**Winner: Lovable** - infrastructure-level defaults provide a baseline, even if incomplete.
The Verdict
| Category | Lovable | Bolt.new | Cursor |
|---|---|---|---|
| Secret Management | 🔴 High risk | 🔴 High risk | 🟡 Medium risk |
| Database Security | 🟡 Medium-High | 🔴 High risk | 🟡 Variable |
| Authentication | 🟡 Medium | 🔴 High risk | 🟡 Medium |
| XSS & Injection | 🟢 Low-Medium | 🟡 Medium | 🟡 Medium |
| Security Headers | 🟡 Medium | 🔴 High risk | 🟡 Variable |
**Overall: Lovable produces the most secure code out of the box**, primarily because it generates RLS policies and complete auth flows by default. But "most secure among AI tools" still means "needs security review before production."
**Cursor is the safest for experienced developers** who know what to ask for. Its incremental approach gives you more control, but it won't protect you from what you don't know to ask.
**Bolt.new prioritizes speed over security** more aggressively than the other two. It's excellent for prototyping but requires the most security hardening before production deployment.
The Common Thread
All three tools share one critical weakness: **they optimize for functional correctness, not security.** None of them will:
Warn you about leaked secrets
Audit RLS policies for correctness
Check for missing security headers
Flag XSS-vulnerable patterns
Validate authentication flows
That's not a criticism - it's a design decision. AI coding tools are built to ship fast. Security review is a separate step.
What To Do About It
Regardless of which tool you use:
**Scan before you ship** - [Run a free SimplyScan scan](/) to catch the most common issues in 30 seconds
**Review database policies** - Read our [RLS policies guide](/blog/rls-policies-explained) to understand what your AI tool generated
**Audit your secrets** - Check our [environment variables guide](/blog/environment-variables-security) to ensure nothing leaked
**Add security headers** - Follow our [CSRF & headers guide](/blog/csrf-security-headers-guide) for the missing layer
Scan Your Platform
[Lovable Security Scanner](/security-scanner/lovable) - scan Lovable apps for exposed keys and missing RLS
[Bolt.new Security Scanner](/security-scanner/bolt) - find vulnerabilities in Bolt.new apps
[Cursor Security Scanner](/security-scanner/cursor) - check Cursor-built apps for hardcoded secrets
[Replit Security Scanner](/security-scanner/replit) - protect your deployed Replit apps
[v0 Security Scanner](/security-scanner/v0) - scan v0-generated code for security issues
Related Reading
[Is Vibe Coding Safe? Security Risks of AI-Generated Code](/blog/is-vibe-coding-safe)
[CVE-2025-48757 Explained: How to Check If Your Lovable App Is Affected](/blog/cve-2025-48757-lovable)
[SimplyScan vs Built-In Platform Security](/blog/simplyscan-vs-platform-security)
[Is Lovable Safe?](/blog/is-lovable-safe) · [Is Bolt.new Safe?](/blog/is-bolt-safe) · [Is Cursor Safe?](/blog/is-cursor-safe)