Security Review Prompts: Find Vulnerabilities in Your Code

AI is a remarkable security reviewer when prompted correctly — and a useless one when asked vaguely to "check this for security issues". The difference is whether you give the AI a threat model, the code in question, and a structured way to report findings.

1. Introduction

Security review is pattern recognition. SQL injection, path traversal, IDOR, weak crypto — these are classes of bug with familiar shapes. AI has seen thousands of examples of each, which means it can often spot them faster than a human reviewer. But it has to be told what to look for, where to look, and how to report what it finds. This tutorial gives you the prompt pattern for that.

2. The Concept Explained

Every security review has three inputs: the code being reviewed, the trust boundary (where user-controlled input enters), and the threat model (what an attacker is trying to achieve). Without all three, AI either misses real issues or invents fake ones.

Imagine asking a security consultant to "look at the code". They would first ask: where does user input come from? What are you most worried about? What does this service protect? AI needs the same priming.

3. The Problem Without This Technique

The default is to paste code and ask "is this secure?". The AI returns a long list of generic platitudes — "use HTTPS", "validate inputs" — that don't actually look at your code.

is this code secure?

[pastes a 100-line function]

4. The Solution

Act as a senior application security engineer. Review the code below.

Stack: Node.js 20, Express 4, PostgreSQL via `pg` library.

Trust boundary:
- Anything inside `req.body`, `req.query`, `req.params`, `req.headers` is
  attacker-controlled.
- `req.user` is set by JWT-verifying middleware and can be trusted.
- The database is internal — its rows are NOT considered user input.

Threat model (in priority order):
1. SQL injection via the search endpoint
2. IDOR (one user accessing another user's data)
3. Unsafe deserialisation, path traversal, command injection
4. Auth/session weaknesses (token leakage, missing checks)
5. Information disclosure in error messages
6. Logic flaws specific to the domain (e.g. negative amounts, race conditions)

Code:

```js
[paste 60–120 lines of one route handler or one module]
```

Output format — one entry per finding, sorted by severity:
- ## [Severity: Critical/High/Medium/Low] Finding title
- Where: file:line range
- Why it matters: 1 sentence
- Exploit sketch: 1–2 sentences showing how an attacker would trigger it
- Minimal fix: a code snippet or 1-paragraph approach

If there are no findings under a given threat, say so explicitly. Do not
invent findings to fill the list.

5. Step-by-Step Breakdown

1. Set the role and stack. "Application security engineer" plus runtime + database + framework. Different stacks have different default footguns.
2. Define the trust boundary explicitly. What's tainted, what isn't. This is the single biggest accuracy lift.
3. List the threat model in priority order. Top three threats first. This tells the AI which patterns to look hardest for.
4. Paste a focused slice of code. One route or one module per review. Whole-codebase reviews dilute attention.
5. Demand a structured finding format. Severity, location, why, exploit sketch, fix. Without structure, findings are hard to triage.
6. Explicitly forbid invention. Tell the AI to say "no findings" rather than padding. This dramatically improves signal-to-noise.

Tip: Always have AI security reviews verified by a human. AI is excellent at recall (finding patterns) and weaker at precision (judging exploitability). A reviewer who looks only at the AI's high/critical findings can triage a large review in minutes.

6. Practice Exercises

7. Key Takeaways