secure-code-reviewlisted

# Secure Code Review A review that produces forty style comments and misses the one auth bypass is worse than no review — it burns the reviewee's attention on noise and buries the thing that matters. This skill finds the thing that matters first. ## Read the whole diff/file before judging anything Don't review line-by-line in isolation — a change that looks fine alone can break an invariant defined elsewhere in the file. Understand what the code is supposed to guarantee before checking whether it does. ## Check these classes explicitly, in priority order 1. **Trust boundaries** — every point where data crosses from a less-trusted zone to a more-trusted one (user input, another service's response, a file read, a sensor reading, a retrieved document). Is it validated *at the boundary*, or does validation happen somewhere downstream where it's easy to skip on a new code path? 2. **Auth/authz** — is every internal service-to-service call actually authenticated, or does the code assume "it's internal, it's fine"? That assumption is the single most common real-world breach vector in distributed systems — internal trust is not a security boundary. 3. **Race conditions / TOCTOU** — check-then-act patterns on shared state, especially across async boundaries or between a permission check and the operation it gates. 4. **Injection** — anywhere a string gets built from untrusted input and then interpreted (SQL, shell, template, deserialization). Check the actual sink, not just wheth