Why This Matters
Fixing a security vulnerability after production is usually far more expensive than fixing it during implementation. Every minute you spend on this checklist reduces the odds of incident response, lawyer calls, and customer-trust rebuild later.
The Problem
AI generates a login endpoint. Looks great. Runs perfectly. Ships to production. Three days later: your database is leaked. The SQL injection was obvious in hindsight, but AI treated user input like trusted data.
The core issue: AI learns from code examples that include security vulnerabilities. Stack Overflow, GitHub, tutorials — many contain insecure patterns. AI statistically reproduces these. It doesn't understand threat models, it generates "typical" code. Typical code is often vulnerable code.
You can't catch these by eyeballing the diff. Without a structured pass, you'll miss the category you didn't think to look for — and AI's confident tone makes the gap invisible.
The Core Insight
Use the OWASP Top 10 as a systematic checklist, not a reading list. The Top 10 isn't trivia — it's a structured taxonomy of how web applications get breached. Walk every AI-generated diff through each category in order. Skip the intuition; trust the framework.
The categories cover what an attacker tries first: broken access control, injection, cryptographic failures, insecure design, security misconfiguration. If your code passes a deliberate sweep across all ten, you've covered ~90% of real-world attack surface. The other 10% lives in language-specific footguns (see the sibling guide on language vulnerabilities).
Think like a penetration tester: every input is malicious, every database query is a potential injection point, every API call is a chance for exploitation. The checklist below is your scoring rubric.
The False Confidence Trap
AI explains its own code with the same confidence whether the code is secure or full of holes. "Looks good" from the model is not a signal — it's noise. This is the input side of the same problem described in AI's Validation Blindspot below: the model's confidence in what it wrote is uncorrelated with whether the code actually handles adversarial inputs. That's exactly why you need the OWASP checklist instead of a "does this look secure?" gut check.
AI's Validation Blindspot
AI almost always validates "happy path" inputs (email format, length limits) but misses adversarial inputs (SQL keywords, XSS payloads, prototype-pollution keys, NoSQL operator objects). The model has been trained on what valid data looks like, not what attackers send. Always test with OWASP attack strings — this is the output side of The False Confidence Trap. The model can't see what it doesn't think to validate, and "I added input validation" never means "I added adversarial input validation."