Defensive Security Review

针对自有代码的防御性审计：先画出信任边界、跟踪数据流向，再逐类排查漏洞，并剔除实际不可达的「理论发现」。

这是一份明确的防御向提示词——在别人发现之前，先找出自有代码中的弱点并修复。顺序本身就是要点：先厘清不可信数据从何进入、什么可信、谁能做什么、什么值得被窃取，再进入分类清单，因此当它检查注入时已经知道哪些输入会到达哪些汇点。「可达性」要求则剔除了让报告不可用的理论性发现。附加章节涵盖依赖项审计，以及在代码尚未存在时对设计做威胁建模。

# Security Review

**Use when:** reviewing your own code, a dependency, or a design for security problems.
**Pairs with:** [code_review.md](code_review.md), [architecture_design.md](architecture_design.md)

This is a defensive prompt. It finds weaknesses in code you own so you can fix them.

---

## The prompt

```text
Security review of code we own. Goal: find weaknesses so we can fix them
before someone else finds them.

STEP 1: MAP THE TRUST BOUNDARIES
Before looking for bugs, draw the map:
- Where does data enter from outside our control? Request bodies, query
  strings, headers, cookies, file uploads, webhooks, message queues,
  third party APIs, environment, command line, filenames, clipboard.
- What is trusted and what is not? Be strict. Data from our own database
  is not trusted if a user put it there.
- Who is allowed to do what? List the roles and the operations.
- What is worth stealing here? Credentials, personal data, payment data,
  session tokens, internal network access, compute.

STEP 2: FOLLOW THE DATA
For each untrusted input, trace it all the way through.
Where does it end up?
- In a query, an ORM filter, or raw SQL
- In a shell command or a process argument
- In a file path
- In HTML, or into the DOM
- In a template
- In a log line
- In a redirect target
- In a deserialiser
- In a regular expression
At each landing point, ask: what is the encoding or validation, and is it
the right one for that context? Validation for one context is not
validation for another.

STEP 3: CHECK THE CATEGORIES
Go one at a time. For each, either name the specific weakness with a
location and how it is reached, or say why the category does not apply.

1. Authentication: how is identity proven, and can that be skipped or
   forged? Session handling, token lifetime, token revocation.
2. Authorisation: is the check on every path, including the one added
   last week? Can I access another user's object by changing an id? Is
   the check on the client only?
3. Injection: SQL, command, template, header, log, path.
4. Output encoding: is data escaped for the context it lands in?
5. Secrets: hardcoded, committed, logged, in an error message, in a
   client bundle, in a stack trace shown to a user.
6. Cryptography: rolled by hand, weak algorithm, reused nonce, predictable
   randomness, comparison that leaks timing.
7. Dependencies: known vulnerable versions, unpinned, unnecessary.
8. Configuration: permissive defaults, debug mode, open CORS, missing
   security headers, verbose errors in production.
9. Denial of service through our own code: unbounded input, unbounded
   query, expensive regular expression, no rate limit, no size limit,
   no timeout.
10. Data exposure: too much returned by an API, personal data in logs,
    missing redaction, an error message that reveals structure.
11. Race conditions with a security effect: check then use, double spend,
    concurrent state change.

STEP 4: THINK LIKE AN ATTACKER, ONE LEVEL UP
- If I have a normal user account, what can I reach that I should not?
- What breaks if I send this endpoint the wrong type, a very large value,
  a negative number, or the same request twice at once?
- What does the system tell me when I get something wrong? Do error
  messages help me enumerate valid values or users?
- If one piece is compromised, what does the attacker get next? How far
  does it spread?

FINDINGS FORMAT
  [Severity] file:line
  Weakness: what is wrong
  Reachability: how untrusted input actually gets there. If it is not
                reachable, say so and drop the severity.
  Impact: what an attacker gains
  Fix: the specific change, with the correct API to use
  Severity: Critical | High | Medium | Low, and why that level

RULES
- Reachability decides severity. An unreachable weakness is a note, not a
  finding.
- No generic advice. "Validate all inputs" is not a finding. Name the
  input, the line, and the validation to add.
- Prefer the framework's built in protection over hand written escaping.
  Say which one.
- If a category is clean, say so in one line. Do not pad the report.
- Rank Critical and High first and keep the list short enough to act on.

END WITH
- The three things to fix first, in order.
- What you could not check and would need to check by other means, such
  as running the app, reviewing infrastructure, or reading a dependency.
```

---

## For dependencies

```text
For each dependency this change adds:
- What does it do that we could not do in fifty lines ourselves?
- How many transitive dependencies does it bring?
- When was it last updated, and by how many maintainers?
- Does it run anything at install time?
- Does it need network or filesystem access at runtime?
Recommend keep or drop for each, with one line of reasoning.
```

---

## For a design, before code exists

```text
Threat model this design.
- What are we protecting and from whom?
- List the trust boundaries. Every arrow that crosses one is a place to
  check.
- For each boundary: what would an attacker try, and what stops them?
- What is the worst case if any single component is fully compromised?
- What do we log, and would we be able to tell afterwards what happened?
Keep it under 500 words and end with the three design changes that reduce
risk the most.
```

---

## Why it works

Most security review prompts produce a checklist recital with no findings, because the model checks categories without tracing data.

The order here matters. Mapping trust boundaries and following the data comes before the category list, so by the time the model reaches "injection" it already knows which inputs reach which sinks. The reachability requirement then removes the theoretical findings that make a report unusable.