Security Risks in AI-Generated Code: What Cursor, Copilot, and Bolt Get Wrong

AI coding assistants have revolutionized how we build software. But they're trained to write code that works, not code that's secure. This creates predictable vulnerability patterns that attackers can exploit.

Based on our analysis of 603 production AI-built applications, here are the specific security risks AI coding tools introduce—and how to address them.

1. Missing Security Headers

The problem: AI tools generate application code, but security headers are configured in deployment settings (Vercel, Netlify, nginx). The AI doesn't know your deployment target, so it skips them entirely.

The risk: Without CSP, your app is vulnerable to XSS attacks. Without X-Frame-Options, you're vulnerable to clickjacking. Without HSTS, you're vulnerable to man-in-the-middle attacks.

The fix: Add security headers to your deployment configuration. See our Security Headers Explained guide for exact configurations.

2. Client-Side Secret Exposure

The problem: When you tell an AI "connect to this API," it puts the API key wherever seems convenient—often directly in the frontend code where it gets bundled and shipped to users.

The risk: Exposed API keys can lead to:

• Billing fraud (attackers use your OpenAI/Stripe/Twilio keys)
• Data theft (attackers access your database with your credentials)
• Account takeover (attackers impersonate your service)

The fix:

• Server-side proxy: Make API calls from your backend, not frontend
• Environment variables: Never hardcode secrets; use .env files excluded from Git
• Scoped keys: Use keys with minimal permissions (e.g., Stripe publishable key for frontend, secret key on backend only)

3. Insecure Backend-as-a-Service Configuration

The problem: AI tools generate working Supabase/Firebase code, but "working" often means disabling security features to avoid errors. Row Level Security (RLS) gets disabled or configured to allow all access.

Common patterns we see:

-- AI-generated: allows anyone to read all users
CREATE POLICY "Allow all" ON users
FOR SELECT USING (true);

-- Should be: users can only read their own data
CREATE POLICY "Users read own data" ON users
FOR SELECT USING (auth.uid() = id);

The risk: Anyone with your Supabase URL (which is in your frontend code) can query your database and read/write data they shouldn't have access to.

The fix:

• Enable RLS on all tables: ALTER TABLE users ENABLE ROW LEVEL SECURITY;
• Write explicit policies that check auth.uid()
• Test policies by trying to access data as different users
• Use Supabase's "Policies" tab in the dashboard to audit

4. Source Map Exposure

The problem: Source maps are debugging files that map minified code back to your original source. They're useful in development, but AI-generated build configurations often don't disable them for production.

The risk: Attackers can read your entire application logic, find vulnerabilities, and understand your business logic. It's like handing them annotated source code.

The fix:

Vite (vite.config.js):

export default defineConfig({
  build: {
    sourcemap: false, // Disable in production
  },
})

Webpack:

module.exports = {
  devtool: "production" === 'production'
    ? false
    : 'source-map',
}

5. Overly Permissive CORS

The problem: When AI-generated code hits a CORS error, the fix is often to allow all origins (*). This works but defeats the purpose of CORS.

The risk: Malicious websites can make authenticated requests to your API on behalf of your users (if cookies are used) or access your API directly.

The fix: Explicitly list allowed origins:

// Instead of: Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: https://yourdomain.com

// Multiple origins require server-side logic:
const allowedOrigins = ['https://yourdomain.com', 'https://app.yourdomain.com'];
const origin = req.headers.origin;
if (allowedOrigins.includes(origin)) {
  res.setHeader('Access-Control-Allow-Origin', origin);
}

6. Missing Input Validation

The problem: AI generates code that handles the "happy path." Input validation—checking that user input is what you expect—is often incomplete or missing.

Common issues:

• SQL queries built with string concatenation instead of parameterized queries
• User input rendered directly in HTML without escaping (XSS)
• File uploads without type or size validation
• Numeric fields accepting strings that break downstream logic

The fix:

• Use parameterized queries or ORMs for database access
• Sanitize user input before rendering (React does this by default, but dangerouslySetInnerHTML bypasses it)
• Validate input types, lengths, and formats on both client and server
• Use libraries like Zod or Yup for schema validation

7. Authentication and Session Issues

The problem: AI implements authentication that works, but often misses security details:

• JWTs stored in localStorage (vulnerable to XSS) instead of httpOnly cookies
• No token expiration or refresh token rotation
• Password reset links that don't expire
• No rate limiting on login endpoints (enables brute force)

The fix:

• Use established auth libraries (NextAuth, Supabase Auth, Auth0) instead of rolling your own
• Store tokens in httpOnly cookies when possible
• Implement token expiration and rotation
• Add rate limiting to auth endpoints

Why AI Tools Create These Vulnerabilities

These patterns aren't bugs—they're features of how AI is trained and used:

1. Training data prioritizes functionality: Most code on GitHub and Stack Overflow focuses on getting things to work, not security hardening
2. Context is limited: The AI doesn't know your deployment target, threat model, or compliance requirements
3. User prompts focus on features: "Build a login form" doesn't imply "with brute force protection and secure session management"
4. Speed over safety: These tools compete on how fast they ship working code

How to Build Securely with AI Tools

1. Explicitly prompt for security: "Add CSRF protection" or "Use parameterized queries"
2. Review generated code: Don't accept code you don't understand
3. Run security scans: Catch issues before deployment
4. Use secure defaults: Configure security headers in your deployment platform
5. Separate secrets: Keep API keys out of client code