Section 1: Reviewing code for security
Where security bugs hide in code
Security review is not reading every line looking for anything odd. It is a targeted search guided by how vulnerabilities actually arise. Most security bugs sit at a small number of places in a code base.
Trust boundaries
A trust boundary is where data crosses from a less trusted source into code that acts on it. The most important boundaries in a typical web service:
- HTTP request parameters, headers, cookies and bodies
- Messages from queues and webhooks from third parties
- Files uploaded by users
- Data read back from storage that users originally wrote
- Responses from other services you do not control
Sources, sinks and sanitisers
Reviewers and tools use the same model:
- A source is where untrusted data enters, such as
request.args. - A sink is a dangerous operation, such as executing SQL, running a command, rendering HTML, making an outbound request or deserialising data.
- A sanitiser is code that makes data safe for a particular sink, such as parameterisation for SQL or escaping for HTML.
A vulnerability usually means: data flows from a source to a sink without passing an appropriate sanitiser. Your review is a hunt for those flows.
The other big family: missing checks
Not every bug is a data flow. Many of the most serious are missing checks:
- An endpoint without an authorisation decision.
- An ownership check on read but not on update.
- A state change without a CSRF protection or idempotency key.
- An error path that skips validation.
These are hard for tools to find, because the tool does not know your business rules. This is where human review adds the most value.
Where to look first
When reviewing a new service, start with:
- Routing and authorisation configuration: list every endpoint and the permission check that guards it.
- Data access layer: any raw queries or dynamic query building.
- Authentication and session code: login, reset, token handling.
- Integrations: outbound HTTP, file handling, deserialisation.
- Configuration: debug flags, CORS, cookie settings, secrets.
Then review the business critical flows end to end, such as payments or permission changes. In the next lesson we turn this into a repeatable routine for pull requests.