Skip to content
← Back to thoughts
5 min read

Security Reviews Beat Style Nits

Why junior developers should treat every PR like a light threat model — not just a lint pass.

The Art of Code Review

Code review is where secure defaults either stick or die. Catching a missing auth check beats arguing about quote styles.

Too many code reviews get bogged down in trivial nitpicks—variable naming preferences, formatting arguments, or stylistic debates. While clean code matters, spending energy on quote styles while missing an unvalidated permission check or a broken access control rule means the review failed its primary security mission.

1. Focus on Trust Boundaries and Threat Models

Ask what trust boundary changed. Who can call this endpoint? What happens if the input is empty, huge, or hostile?

  • Trace the Data Flow: When reviewing a pull request, don't just look at the happy path. Ask yourself: Where did this data originate? Does it cross a trust boundary (e.g., from an unauthenticated user to a database query)?
  • Anticipate Edge Cases: Push the code to its limits mentally. What happens if a user submits an empty string, an arbitrarily massive payload, or malicious SQL/XSS input? If the code assumes inputs are always well-behaved, it's vulnerable.

2. Separate Human Intent from System Reality

Assume good intent from the author — and zero trust from the network.

  • Be a Collaborator, Not a Gatekeeper: Approach reviews assuming your teammate is smart and well-meaning. Frame feedback constructively rather than critically.
  • Maintain Zero Trust for the Code: While you trust the author, you must never trust the code until it proves itself. Treat every incoming request, API call, and variable as potentially hostile.

3. Prioritize in Layers

Separate taste from correctness, then from security.

To keep reviews efficient and impactful, tackle feedback in a strict hierarchy:

  1. Security & Correctness First: Does this code introduce vulnerabilities, race conditions, logic errors, or missing auth checks?
  2. Architecture & Maintainability: Is the logic clean, testable, and maintainable?
  3. Style & Taste Last: Are variable names clear? Does it match the team's formatting standards? (Ideally, let linters handle this automatically so humans don't have to).

4. The Real Goal of Code Review

The goal is a safer codebase and a stronger team, not winning the thread.

Code reviews are not an intellectual sparring match or a place to prove how smart you are. The ultimate metric of a great code review isn't how many comments you left—it's whether the resulting codebase is safer, whether the team learned something valuable, and whether everyone feels supported along the way.