Here's a stat that should keep you up at night: 24.7% of AI-generated code contains security vulnerabilities. Nearly 45% of those hit the OWASP Top 10 — the most common, most exploitable categories of web security flaws.

This isn't because AI is bad at coding. It's because AI optimizes for making things work, not making them safe. When you ask it to "add a user login," it builds a functional login. It doesn't think about session fixation, brute force protection, or what happens when someone puts a SQL statement in the email field.

If you've built an app with Cursor, Bolt.new, Lovable, or any AI coding tool and you're about to ship it to real users — run through this checklist first. Each item takes 5-15 minutes. All of them together could save you from a breach that kills your product.

1. Secrets Are Not in Your Code

This is the most common and most dangerous mistake in AI-built apps. AI tools love to hardcode API keys, database URLs, and secrets directly in the source code.

Check for:

• API keys in JavaScript/TypeScript files (search for sk-, pk_, key_, secret)
• Database connection strings in source code
• JWT secrets hardcoded in auth files
• Third-party service credentials (Stripe, SendGrid, AWS) in client-side code

How to fix:

# Search your codebase for exposed secrets
grep -rn "sk_live\|sk_test\|password\|secret\|api_key\|apiKey" src/

# Move all secrets to environment variables
# .env.local (never committed to git)
DATABASE_URL=postgres://...
STRIPE_SECRET_KEY=sk_live_...
JWT_SECRET=your-secret-here

# .gitignore (make sure this exists)
.env
.env.local
.env.production

Critical: If secrets were ever committed to git, they're in the history even after removal. Rotate them immediately — generate new keys and revoke the old ones.

2. All User Input Is Validated

AI-generated code almost never validates input properly. It trusts whatever the user sends, which opens the door to injection attacks, crashes, and data corruption.

Check for:

• Form inputs used directly without validation
• API route parameters used without type checking
• Database queries built from user input (SQL injection risk)
• File uploads without type/size restrictions

How to fix:

// Use Zod for input validation in API routes
import { z } from 'zod';

const CreateUserSchema = z.object({
  email: z.string().email().max(255),
  name: z.string().min(1).max(100),
  age: z.number().int().min(13).max(150).optional(),
});

export async function POST(request: Request) {
  const body = await request.json();
  const result = CreateUserSchema.safeParse(body);

  if (!result.success) {
    return Response.json(
      { error: result.error.flatten() },
      { status: 400 }
    );
  }

  const { email, name, age } = result.data;
  // ... safe to use
}

Validate on the server, always. Client-side validation is for UX — server-side validation is for security. Never trust the client.

3. Authentication Is Actually Protecting Routes

AI tools often generate auth that looks right but has gaps. The login page works, but the API routes behind it? Wide open.

Check for:

• API routes that should require authentication but don't check for a session
• Middleware that checks auth on some routes but misses others
• Admin-only endpoints accessible to regular users (broken access control)
• Direct object references — can user A access user B's data by changing an ID in the URL?

Quick test: Open your browser's dev tools, find an API call your app makes, copy it as a cURL command, remove the auth cookie/token, and run it. If it still returns data, your route isn't protected.

// Every protected API route should start with this
export async function GET(request: Request) {
  const session = await getSession(request);
  if (!session) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 });
  }

  // For user-specific data, always filter by the authenticated user
  const data = await db.query.items.findMany({
    where: eq(items.userId, session.user.id), // NOT from URL params
  });

  return Response.json(data);
}

4. No Sensitive Data in Client-Side Code

Everything in your frontend JavaScript is visible to anyone who opens dev tools. AI tools frequently put things on the client side that should stay on the server.

Check for:

• API keys in .env files prefixed with NEXT_PUBLIC_ that shouldn't be public
• Business logic that reveals pricing algorithms, discount rules, or internal calculations
• Error messages that expose database schema, file paths, or internal system details
• User data from other users leaking into API responses (overfetching)

How to fix:

• Only prefix env variables with NEXT_PUBLIC_ if they're truly meant to be public
• Move business logic to server-side API routes or server components
• Return generic error messages to the client, log detailed errors on the server
• Shape API responses to include only what the requesting user needs to see

5. Rate Limiting Exists

Without rate limiting, anyone can hammer your API thousands of times per second. This leads to DDoS vulnerability, brute force attacks on login, and runaway costs on pay-per-use services (like AI APIs).

AI-generated code almost never includes rate limiting.

What to protect:

• Login/signup endpoints — prevent brute force (5-10 attempts per minute)
• AI generation endpoints — prevent cost abuse
• Password reset — prevent email bombing (2-3 per hour)
• General API — prevent abuse (100-1000 requests per minute)

// Using Upstash Redis for serverless rate limiting
import { Ratelimit } from '@upstash/ratelimit';
import { Redis } from '@upstash/redis';

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(10, '1 m'),
});

export async function POST(request: Request) {
  const ip = request.headers.get('x-forwarded-for') ?? '127.0.0.1';
  const { success } = await ratelimit.limit(ip);

  if (!success) {
    return Response.json(
      { error: 'Too many requests' },
      { status: 429 }
    );
  }
  // ... handle request
}

6. Dependencies Are Not a Liability

AI tools add npm packages liberally. Each dependency is code you didn't write running in your app. Some may have known vulnerabilities, be abandoned, or even be malicious.

# Check for known vulnerabilities
npm audit

# See what you've got installed
npm ls --depth=0

# Check for unused dependencies
npx depcheck

Fix critical and high vulnerabilities. Remove packages you don't use.

7. HTTPS, Headers, and CORS Are Configured

The boring infrastructure stuff that AI never sets up but attackers always check.

Essential security headers (add to next.config.ts):

const securityHeaders = [
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'X-XSS-Protection', value: '1; mode=block' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
];

const nextConfig = {
  async headers() {
    return [{ source: '/(.*)', headers: securityHeaders }];
  },
};

CORS: If your API is only used by your own frontend, don't enable CORS at all. If you need CORS, whitelist specific origins — never use * in production.

The 15-Minute Security Sprint

If you can only do one thing from this list, here's the priority order:

1. Secrets audit (5 min) — grep for exposed keys. Highest-impact, easiest-to-exploit.
2. Auth check (5 min) — test your API routes without authentication. Find the gaps.
3. Input validation (5 min) — add Zod to your most critical endpoint.

These three catch the majority of real-world attacks on AI-built apps.

A security breach doesn't just break your app. It breaks trust. Users whose data gets leaked don't come back.

AI made it possible to build an app in a weekend. But shipping it without a security review is like driving a car without brakes — it works fine until it doesn't, and when it fails, it fails catastrophically.

Spend the hour. Run the checklist. Ship with confidence.

Originally published at bivecode.com