Top 5 Vulnerabilities We Found in 500+ Apps Built with Cursor, v0, and Bolt

At SafeLaunch, we've scanned over 500 repositories built primarily with AI coding tools — Cursor, v0, Bolt, Lovable, and Claude Code. These tools are transforming how software gets built. A solo developer can now ship in days what used to take a team weeks. But speed comes with trade-offs, and security is consistently the biggest one.

Here are the 5 most common vulnerabilities we've found, ranked by frequency and severity. If you've built anything with AI assistance, there's a high chance at least one of these applies to your project.

#1. Exposed Environment Variables in Client-Side Code (Found in 61% of apps)

This is the single most common issue. In Next.js, any environment variable prefixed with NEXT_PUBLIC_ is bundled into the client-side JavaScript — visible to anyone who opens browser DevTools. We've found Supabase service role keys, Stripe secret keys, and even database connection strings exposed this way.

The root cause: AI assistants don't always distinguish between server-only and client-safe environment variables. When you ask for a Supabase integration, the AI might use the service role key on the client side because it works. The fix is simple — audit every NEXT_PUBLIC_ variable and ensure no secret keys are exposed. Server-side operations should use server-only environment variables through API routes or server components.

#2. Authentication Bypass via Direct API Access (Found in 47% of apps)

Many AI-built apps implement authentication on the frontend — showing/hiding UI elements based on login state — but forget to protect the API routes themselves. This means anyone with basic HTTP knowledge can call your API directly and bypass all your frontend auth checks.

We found apps where /api/admin/* endpoints returned full user lists, billing data, and even allowed account deletion with no server-side auth verification. The pattern is always the same: the AI generated beautiful protected routes in React, but the underlying API handlers have no middleware checking the session or JWT.

The fix: every API route must independently verify authentication. In Next.js with Supabase, this means calling supabase.auth.getUser() at the top of every route handler. Never rely on the frontend to enforce access control.

#3. Vulnerable Dependencies with Known CVEs (Found in 44% of apps)

AI tools suggest packages based on their training data, which may include outdated versions with known vulnerabilities. We regularly find projects using vulnerable versions of packages like axios, jsonwebtoken, node-fetch, and various webpack plugins.

One particularly concerning pattern: AI assistants sometimes suggest deprecated packages that have been replaced by more secure alternatives. For example, suggesting `request` (deprecated since 2020) instead of `fetch` or `axios`, or `crypto-js` for operations that should use Node's built-in `crypto` module.

Make `npm audit` part of your workflow. Better yet, use automated tools that continuously monitor your dependencies. A vulnerability discovered today in a package you installed last week is still your problem.

#4. Missing or Misconfigured Security Headers (Found in 38% of apps)

Security headers are your first line of defense against XSS, clickjacking, and data injection attacks. But AI-generated code almost never includes them. We're talking about headers like Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and Strict-Transport-Security.

In Next.js, you can add these in next.config.js or middleware. The absence of a Content-Security-Policy header means any injected script can run freely on your page. Without X-Frame-Options, your app can be embedded in an iframe on a malicious site for clickjacking attacks.

#5. Unvalidated Redirect and Server-Side Request Forgery (Found in 29% of apps)

AI-generated code that handles URLs — redirect parameters, webhook endpoints, image proxies — often passes user input directly to HTTP requests or redirects without validation. This opens the door to SSRF (Server-Side Request Forgery), where an attacker can make your server access internal resources, and open redirect attacks that can be used for phishing.

The pattern we see most: a callback URL parameter like /auth/callback?redirect=/dashboard that accepts any URL, including https://evil-site.com. Or an image proxy that fetches any URL passed to it, including internal network addresses like http://169.254.169.254 (the AWS metadata endpoint).

Always validate and whitelist URLs before redirecting or fetching. For redirects, only allow relative paths or a known list of domains. For server-side fetches, block private IP ranges and internal hostnames.

The Pattern Behind the Pattern

All five vulnerabilities share a common root cause: AI coding tools optimize for functionality, not security. They generate code that works correctly under normal usage but doesn't defend against adversarial input. This isn't going to change anytime soon — these tools are trained to solve the problem you describe, and most prompts don't describe security requirements.

The solution isn't to stop using AI tools — they're too valuable for that. The solution is to add a security check as the final step before every deployment. Whether you do it manually or use a tool like SafeLaunch, make it a habit. Your users are trusting you with their data. That trust should be earned.