Why it matters
Reading the code finds a problem at its source, often long before a tester could reach it from outside. A fix at that stage is a few lines in a pull request, not an emergency patch. It also teaches the team what a risky pattern looks like, so the same mistake appears less often.
What reviewers look for
- Authentication and sessions: how users prove who they are and how that proof is kept.
- Authorisation: whether every request checks that this user may do this thing to this record.
- Input and output handling: where untrusted data reaches a database, a page or a command, the root of SQL injection and cross-site scripting.
- Secrets: keys and passwords kept out of the repository and out of logs.
- Dependencies: libraries with known vulnerabilities.
- Errors and logging: nothing sensitive in messages, and enough detail to investigate an incident.
Tools and people
Static analysis tools are quick and find known patterns, such as a query built from joined strings. They are poor at flaws in logic, like a missing ownership check. That is broken access control, which sits near the top of the OWASP Top 10, and a person who understands what the product is meant to do catches it. Use both.
Common mistakes
- Trusting the tool and skipping the human read.
- Reviewing only the changed lines, without the code around them.
- Waiting until the end, when changes are large and hard to undo.
- Reviewing without a threat model, so the effort goes to the wrong places.
Related terms
A review looks from the inside, while penetration testing looks from the outside. They find different things, so they work well together. Read about our secure code review.