The AI Code Security Checklist Every Founder Needs

AI coding tools are not security engineers. They’re pattern completers. They generate code that looks like the code they were trained on — and most code in training data wasn’t written with adversarial users in mind.

This isn’t a criticism of the tools. It’s an architectural reality. Claude, Cursor, Copilot, and Bolt generate code that satisfies the specified requirements. If you don’t specify “and make it secure,” you won’t get security.

The checklist below is what we use when onboarding a new AI-generated codebase. It maps to OWASP Top 10 and covers the failure modes we see most often. Work through it systematically — most issues can be fixed in hours once identified.

1. Injection Prevention

Check: Are all database queries parameterized?

SQL injection is still the most common vulnerability in AI-generated code because the natural way to construct queries with string formatting is also the dangerous way.

# Dangerous — generated frequently by AI tools
cursor.execute(f"SELECT * FROM users WHERE email = '{email}'")

# Safe — parameterized query
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))

Action: Search your codebase for every SQL query. Any query built with string formatting or concatenation is a vulnerability. Replace with parameterized queries or an ORM that handles this by default.

Also check: NoSQL injection (MongoDB query operators in user input), command injection (shell commands built from user input), LDAP injection if applicable.

2. Authentication

Check: Are all non-public endpoints protected?

AI tools generate authentication endpoints correctly. They’re less reliable at consistently applying that authentication everywhere else.

Action: List every endpoint in your application. For each one, verify: (a) does it require authentication where it should, and (b) does it check that the authenticated user has permission to access that specific resource?

The second check — authorization — is where most codebases fail. Authentication tells you who the user is. Authorization tells you what they’re allowed to do. An endpoint that returns any user’s data to any authenticated user is an authorization failure, not an authentication failure.

Also check:

• Password hashing uses bcrypt, scrypt, or Argon2 (not MD5, SHA1, or plain SHA256)
• Password reset tokens are cryptographically random and expire after use
• JWT tokens use strong signing algorithms (RS256 or ES256, not HS256 with a weak secret)
• Session tokens are invalidated on logout

3. Sensitive Data Exposure

Check: Where are secrets stored?

This is the most common critical finding in AI-generated codebases. API keys, database passwords, and JWT secrets committed directly to version control. Sometimes in the main application file. Sometimes in a .env file that’s tracked by git.

Action: Run git log -p | grep -i "api_key\|secret\|password\|token" to find historical commits with secrets. If you find any, rotate them immediately — they should be considered compromised.

Then:

• Add .env to .gitignore if it isn’t already
• Move all secrets to environment variables loaded from a secrets manager
• Use a tool like detect-secrets or truffleHog as a pre-commit hook to prevent future commits of secrets
• Audit your current environment for secrets that should be rotated

Also check:

• Sensitive data (passwords, credit cards, SSNs) is not logged
• API responses don’t include more data than the client needs
• Error messages don’t expose stack traces, database structure, or internal paths to users

4. Security Misconfiguration

Check: Are debug modes disabled in production?

AI-generated applications often run in development mode by default. Development mode typically exposes detailed error messages, internal stack traces, and sometimes interactive debuggers — all useful for development, all dangerous in production.

Action: Verify that DEBUG=False (or equivalent) in production. Check that your web framework isn’t returning detailed error pages to end users. Verify that any admin interfaces are not publicly accessible.

Also check:

• CORS is configured specifically, not with * wildcard
• Security headers are set: X-Content-Type-Options, X-Frame-Options, Content-Security-Policy
• Default credentials are changed on all services
• Unnecessary ports and services are not exposed

5. Rate Limiting and Brute Force Protection

Check: Are authentication endpoints rate-limited?

AI-generated login endpoints process every request without limit. An attacker can attempt millions of password combinations or email addresses without triggering any protection.

Action: Add rate limiting to authentication endpoints (login, password reset, registration). The specific limits depend on your use case, but a starting point: 10 attempts per IP per 15-minute window, with exponential backoff after the first few failures.

Also check:

• Account lockout after repeated failed login attempts
• CAPTCHA or equivalent for public-facing forms
• Rate limiting on API endpoints proportional to their cost

6. Dependency Vulnerabilities

Check: When did you last audit your dependencies?

AI tools generate requirements files that pin to whatever version was current when the model was trained. Security vulnerabilities are discovered and patched constantly. Your dependencies are almost certainly out of date.

Action: Run a dependency audit now:

# Python
pip audit

# Node.js
npm audit

# Both
snyk test

Fix critical and high vulnerabilities first. Review medium and low vulnerabilities in the context of your application.

Also check:

• Dependencies are pinned to specific versions in production (not ranges)
• You have a process for receiving security advisories for your dependencies
• Unused dependencies are removed

7. Input Validation

Check: Is all user input validated server-side?

Client-side validation (JavaScript in the browser) is for user experience, not security. Any validation that only exists in the browser can be bypassed by anyone making direct HTTP requests to your API.

Action: Every piece of data entering your system from outside should be validated server-side: type, format, length, range, and allowed values. Use a schema validation library (Pydantic, Zod, Joi) rather than manual checks — it’s harder to miss cases.

Also check:

• File upload endpoints validate file type server-side (not just by extension)
• Uploaded files are stored outside the web root if executing them would be dangerous
• URL parameters and path segments are validated, not just request bodies

8. Error Handling

Check: Do unhandled exceptions expose information to users?

A stack trace in a user-facing error response is both a poor user experience and a security issue — it reveals your technology stack, file paths, and sometimes partial data from memory.

Action: Implement a global error handler that logs the full error internally and returns a generic message to the user. The full details are for your logs; the user gets “something went wrong” and a reference ID they can use to report the issue.

# Every user-facing error should look like this
@app.exception_handler(Exception)
async def global_exception_handler(request, exc):
    logger.error("unhandled_exception", error=str(exc), trace=traceback.format_exc())
    return JSONResponse(
        status_code=500,
        content={"error": "Internal server error", "reference": generate_reference_id()}
    )

Running This Checklist

Don’t try to fix everything at once. Prioritize by impact:

1. Immediate (do today): Secrets in version control, SQL injection vulnerabilities, debug mode in production
2. This week: Authentication/authorization gaps, missing rate limiting, dependency vulnerabilities
3. This sprint: Input validation, error handling, security headers, CORS configuration

Each item on this list has a corresponding check in the Production-Readiness Scorecard in our free playbook. The scorecard includes severity ratings and fix templates for each finding — download it and use it as your audit template.

Security isn’t a one-time fix. It’s a practice. Start with this checklist, fix what you find, then build the habit of reviewing new code against these categories before it ships.