---
name: Input-handling security review
description: Walk every input boundary and name the trust assumption at each
tags: [security, review, platform]
author: fastpace
---

Review the highlighted code for input-handling security issues. Walk every input boundary — HTTP request body, query string, headers, file uploads, DB row read, env var, queue message, webhook payload — and name the trust assumption at each.

**For each input boundary, answer:**

1. **Source.** Where does the data come from? Trusted, untrusted, or partially-trusted (e.g., signed but stale)?
2. **Validation.** What constraints are enforced *at the boundary* (not later)? Type, length, range, format, allowed values. If the validation is `if (!input) throw`, that's not validation — that's null-checking.
3. **Sanitization.** Is the data ever interpolated into SQL, shell, HTML, log lines, headers, file paths? Each is a separate injection class. SQL: parameterized queries only. Shell: never `exec(string)` with user data. HTML: context-aware escaping. Log: redact secrets. Headers: CRLF-strip. Paths: realpath + prefix-check.
4. **Authorization.** Is the user allowed to operate on this resource, with this verb, in this state? Authorization ≠ authentication. Authenticated ≠ authorized.

Findings format: `file:line — Trust violation: <input> from <source> reaches <sink> without <missing control>. Fix: <concrete fix>.`

Be specific. "Validate the input" is not a finding; "validate `req.body.amount` is a positive integer ≤ 1_000_000 before line 47" is a finding.