Security Review Checklist

A security review turns broad principles into repeatable questions for a concrete change. The goal is to find missing boundaries, unsafe assumptions, and operational gaps before they reach production.

Core Controls

• Identify attacker-controlled inputs and valuable outputs.
• Check authentication, authorisation, ownership, and least privilege.
• Review interpreter boundaries: HTML, SQL, shell, filesystem, URLs, and templates.
• Review state changes for CSRF, replay, idempotency, and abuse limits.
• Check secrets, logging, dependencies, configuration, and failure behaviour.

Review One Feature End To End

For a document-sharing feature, trace the flow:

create share -> generate token -> store digest and expiry
open share   -> validate token -> authorise scope -> read private file
revoke share -> authorise owner -> invalidate token

Ask who can create, open, and revoke a share. Decide whether the link expires, whether it can be used more than once, and what happens after the owner loses access to the source document.

Test The Rejected Paths

A security review needs more than one happy-path test:

anonymous user tries to create a share
non-owner tries to share another user's document
expired token is presented
revoked token is presented
valid token is altered
download path is missing
request rate becomes abusive
logs are checked for raw tokens

These tests often expose missing boundary decisions faster than a broad checklist alone.

Review Operations Too

Check storage visibility, signed-URL behaviour, secret rotation, audit logs, alerting, dependency ownership, and failure handling. A feature can be secure in one controller and still leak through public object storage or verbose logs.

In Application Work

Keep reviews proportional to risk, but do not skip routine checks on ordinary features. Many serious issues hide in small downloads, admin helpers, and background jobs.

What To Check

Before moving on, make sure you can trace one feature end to end, identify assets and actors, review interpreter and storage boundaries, and write normal, rejected, and abuse-oriented tests.