API Code Review Patterns

Quick Guide: Review a backend diff's inputs and outputs before anything else in it: what enters without a schema, what reaches an interpreter or an outbound request as part of a string, which route answers without checking whose row it returns, and which fields leave in a response, a log or an error. Those are Must Fix and block approval; error text and query shape are Should Fix, addressed before merge without blocking it; the rest of the codebase's habits are not this diff's findings. Two facts change the verdict often enough to hold up front: a tagged sql template binds its interpolated values, so the injection is the untagged template literal; and an argument array keeps the shell out but not the program's own option parser.

Detailed Resources:

• examples/core.md — before-and-after code for each pattern below, under the same headings

<critical_requirements>

Before reviewing API code

Follow every value the diff reads from a request — body, params, query, headers, cookies — to the line that uses it. The defect lives at the use: a handler that parses its body and then reads limit raw from the query string is unvalidated exactly where it matters.

Treat request data reaching SQL, a shell, a file path or an outbound URL as Must Fix unless it arrives as a bound parameter, an argument-array element that cannot start with -, a path confirmed inside its base directory, or an allowlisted value. Spliced into a string something else parses, data becomes instructions, and nothing downstream can tell the two apart.

For every route the diff adds or changes, find the guard that authenticates the caller and the condition that ties the row to them. Authentication says who is asking; without the ownership condition, changing the id in the URL returns someone else's row.