Sink-First Code Review

Sometimes the fastest way to review code is to start at the thing that would hurt if it were abused.

Instead of asking, “Is this interface vulnerable?”, ask, “What would be dangerous if untrusted input reached this operation?”

Start At The Sharp Edges

Look for code that:

• Sends data somewhere else.
• Reads or writes files.
• Evaluates expressions or templates.
• Deserializes structured input.
• Handles sensitive access material.
• Makes authorization, ownership, or tenant-boundary decisions.
• Runs work later in a job, queue, or callback.

Walk Backward

1. Identify the sensitive operation.
2. Name the value that reaches it.
3. Trace that value back to the first user-controlled source.
4. List every validation, normalization, and authorization check in between.
5. Look for fields that take a different path than their neighbors.
6. Write the risk as a broken assumption, not a vulnerability label.

Checks To Map

Check	What To Ask
Shape	Is the input type, size, and structure constrained?
Meaning	Is the value parsed, normalized, decoded, or reinterpreted?
Authorization	Is the caller allowed to perform this action on this object?
Isolation	Can one user, tenant, job, or workflow influence another?
Output	Where does the result go, and who trusts it?
Failure	What happens when a check errors, times out, or is skipped?

Review Template

Input from [source] reaches [sensitive operation].
The intended control is [check].
The open question is whether [assumption] always holds.
The next safe validation step is [benign test or code review task].

When To Stop

Stop when the assumption is proven, disproven, or no longer testable with the information you have. Write down the blocker. A clear “not reachable because of this control” is still useful security work.