AI Prompts for Security Code Reviews

Quick-Start (Copy This Right Now)

Most security code review guides are wrong about one thing: they treat security as a checklist. OWASP Top 10. XSS. SQL injection. Check, check, check.

The real security vulnerabilities that cause breaches aren't in the checklist. They're in the logic — the combination of individually safe operations that becomes unsafe when assembled. And that's where AI security code review prompts can genuinely add value, because an AI that understands your entire codebase can spot logic-level issues that a scanner never would.

Here's the prompt that goes beyond the checklist:

You are a senior application security engineer performing a threat-model-driven code review.

Context: This code handles [describe: user authentication / payment processing / file uploads / API access / etc.] for [describe the application type and its sensitivity level].

Threat model — review for these specific attack scenarios:
1. An authenticated user trying to access another user's data (horizontal privilege escalation)
2. A regular user trying to perform admin-only actions (vertical privilege escalation)
3. An attacker who can influence one input field trying to affect other users or system state
4. A user submitting unexpected input types (null, very large values, Unicode edge cases, special characters)
5. A user who intercepts and replays a valid request at a different time

Code to review: [paste]

For each issue found: describe the attack scenario, explain what the code does wrong, rate severity (Critical/High/Medium/Low), and suggest the fix with a code example.

What this does: Anchors the review in attacker scenarios, not just vulnerability categories. "Horizontal privilege escalation" gives the AI a concrete attack to look for — rather than a generic "check for access control issues."

Understanding the Variables

Context description — the same code has different risk profiles depending on what it does. A function that reads a user's public profile has lower security stakes than one that processes payment tokens. Giving the AI this context produces appropriately-calibrated severity ratings.

Threat model scenarios — these five scenarios cover the most common application-level attack patterns. They're not exhaustive, but they're the ones that appear in breach reports most frequently. Add scenarios specific to your application type.

"Code example" in the fix — asking for a code example alongside the description turns security findings into actionable PRs rather than abstract recommendations.

⚡ Pro tip: Add "identify any place in this code where the fix requires a decision about business requirements, not just technical implementation." Security fixes sometimes have product implications — an auth check that works technically might break a legitimate workflow. Flagging these upfront prevents fixes that create different problems.

Step-by-Step: AI Security Code Reviews

Step 1: Run the authentication and authorization pass first.

Authorization bugs — wrong user accessing wrong data — are the most common security issue in web applications and the hardest to catch with automated scanners.

Review this code specifically for authorization failures. For each data access or modification:
1. Is the current user's identity verified before the operation?
2. Is the user's permission to perform THIS specific operation checked (not just "is user logged in")?
3. Is the object being accessed validated to belong to the current user?
4. Could a user manipulate any parameter (URL path, query string, request body) to access a different object?

Code: [paste]
User authentication context: [describe how auth works — JWT, session, etc.]

What this does: Forces an object-level authorization check for every data access — catching the "IDOR" (Insecure Direct Object Reference) vulnerability class that appears in nearly every OWASP list and nearly every bug bounty program.

Step 2: Input validation and output encoding pass.

Review this code for injection vulnerabilities. Check:
1. SQL: any user input concatenated into SQL strings (vs parameterized queries)
2. Command injection: any user input used in shell commands
3. Path traversal: any user input used in file paths
4. XSS: any user input rendered in HTML without encoding
5. JSON injection: any user input embedded in JSON strings
6. SSRF: any URL constructed from user input

For each finding: show the vulnerable line, the attack payload that would exploit it, and the safe alternative.

What this does: The "attack payload" requirement is the key addition. Showing the specific payload that would work demonstrates exploitability concretely — which helps prioritize remediation.

⚠️ Common mistake: Running a security code review prompt on individual functions in isolation. Many authorization bugs only appear when two functions are used together — one that retrieves a resource ID and one that performs an operation on it. Always include enough context to see the call chain.

⚡ Pro tip: For security reviews of APIs, add: "Review the HTTP response headers for security-relevant headers: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, and Referrer-Policy. Flag any missing headers and their significance." Security headers are frequently absent in AI-generated API code and easily added once flagged.

Pro-Level Variations

For cryptography review:

Review this code's use of cryptography. Check: use of deprecated algorithms (MD5, SHA1 for signatures, DES, RC4), hardcoded keys or IVs, non-random IV generation for symmetric encryption, use of ECB mode, password storage without a proper KDF (bcrypt, scrypt, Argon2), and token generation using non-cryptographic randomness. For each finding, explain the practical attack that's possible.

For third-party dependency review:

Review the dependencies in this package.json/requirements.txt for security concerns. Check: known vulnerabilities (reference CVE database conventions), packages that request excessive filesystem or network permissions, packages with very few downloads or recent ownership changes (supply chain risk), and packages that are unmaintained (last commit over 2 years ago). Suggest safer alternatives where available.

For secrets detection:

Review this codebase for accidentally committed secrets. Look for: API keys (typically alphanumeric strings 20+ chars), JWT secrets, database connection strings with passwords, private keys (PEM format), OAuth client secrets, and webhook URLs containing tokens. For each finding: flag the file and line, classify what type of secret it appears to be, and confirm whether this is a false positive based on naming context.

Troubleshooting Common Issues

Problem: AI finds too many false positives. Fix: Add "rate your confidence in each finding as High/Medium/Low. Only report Low confidence findings if they're Critical or High severity."

Problem: Security findings are too abstract to act on. Fix: Add "for each finding, provide a minimum viable test case that would demonstrate the vulnerability."

Problem: AI misses context-specific vulnerabilities. Fix: Add a paragraph describing your threat model: who are the attackers, what would they want, and what systems would they attack first.

Your Turn

Security code review is one of the highest-value applications of AI in the development workflow — because a thorough security review takes expertise and time that most teams don't have on demand. A well-structured ai prompts security code review prompt gives every developer access to senior-level security thinking on every PR.

Build your threat-model-specific prompts and save them in PromptABCD — one for authentication/authorization, one for injection vulnerabilities, one for cryptography. Your security review library is ready when you need it.

Building a Security Review Culture

Individual security reviews catch individual vulnerabilities. A team security review culture catches systemic patterns — the architectural decisions that create vulnerability classes across multiple features.

A prompt for systemic security thinking:

Review this codebase's overall authentication and authorization architecture, not just individual code blocks. Answer:
1. Where is the single source of truth for "is this user allowed to do X"? Is it consistently applied?
2. Is there any feature that bypasses the standard auth flow? If so, is the bypass intentional and documented?
3. Are there any admin functions that rely on a client-supplied flag ("is_admin: true") rather than server-side verification?
4. How would you test that the authorization system can't be bypassed — what's the test strategy?

Codebase areas to review: [list your auth-related files]

What this does: Shifts from reviewing individual functions to reviewing the authorization model as a system — which catches the architectural gaps that function-level review misses entirely.

⚡ Pro tip: For teams building security review into their development process, create a security review checklist prompt that's run on every PR touching authentication, payment processing, or data access code: "Run the standard security review for any PR touching: auth/, payments/, or data-export/*. Check: new authorization paths, new data access patterns, new external calls, and any new fields that might contain PII." Automating the trigger makes security review a habit rather than a heroic effort.

Incident Response and Security Logging

Security code review should include a logging review — because the logs are what you'll use during an incident:

Review this code for security-relevant logging. Every security event should be logged: authentication attempts (success and failure), authorization failures, admin actions, and data exports. Check:
- Are all auth failures logged with enough context to detect brute force?
- Are admin actions logged with the admin's user ID and the target of the action?
- Is any PII being logged? (email addresses, SSNs, payment details should be masked or excluded)
- Are log entries structured (JSON) so they can be queried in a SIEM?

What this does: Security logging is the audit trail that makes incident response possible. Missing it is a compliance risk and an operational blind spot. ⚡ Pro tip: For teams doing regular security reviews, ask the AI to generate a security test plan alongside the code review: 'Given these security findings, write a manual penetration test plan that a developer could execute in 2 hours. For each finding, specify: the test URL or code path, the specific input to try, and the expected response if the vulnerability exists.' Security findings that come with test plans get fixed faster — because verification is built into the ticket.

Save this prompt in your ai prompts security code review library — run it on every service that handles sensitive data.