OWASP Secure Code Review
Secure code review means reading source code with security questions in mind. Reviewers catch flaws that testing misses, and they catch them early, when fixes cost the least. Both manual reading and automated tools play a role.
The Proofreader Comparison
An author rereads a draft and misses typos because the brain fills in the intended words. A fresh proofreader spots them quickly. A second set of eyes on code works the same way, and a reviewer with security training spots risky patterns that the author never considered.
Review Workflow
Developer opens change request
|
↓
Automated checks run (static analysis, secret scan, dependency scan)
|
↓
Reviewer reads the change with a security checklist
|
↓
Findings discussed and fixed
|
↓
Change approved and merged
Manual Review Versus Automated Tools
| Approach | Strength | Weakness |
|---|---|---|
| Manual review | Understands business logic and context | Slow and depends on reviewer skill |
| Static analysis tools | Scan large code bases fast and consistently | Produce false alarms and miss logic flaws |
Strong programs combine both.
A Security Checklist for Reviewers
| Area | Question to Ask |
|---|---|
| Input handling | Does the code validate every external value on the server? |
| Database access | Do queries use parameters instead of string joins? |
| Output | Does the page encode user data for its context? |
| Authentication | Do sensitive routes require login and the right role? |
| Authorization | Does the code check ownership of each record? |
| Cryptography | Does the code use vetted libraries and modern algorithms? |
| Secrets | Does the change contain keys, tokens, or passwords? |
| Errors and logging | Do error messages avoid internal details, and do logs avoid sensitive data? |
Spot the Flaw: A Short Example
Risky Code
query = "SELECT * FROM users WHERE email = '" + email + "'"
cursor.execute(query)
The code joins user input directly into the query text. A reviewer flags this line immediately.
Safer Code
query = "SELECT * FROM users WHERE email = %s"
cursor.execute(query, (email,))
The database receives the command and the value separately, so the value never changes the command.
Where to Focus First
Time is limited, so reviewers concentrate on high-risk areas: login and password reset, payment code, file handling, code that calls the operating system, data access layers, and anything that processes input from outside. Changes to security-related libraries deserve extra attention.
Habits of Effective Reviewers
- Understand the purpose of the change before reading line by line.
- Follow the path of untrusted data from entry point to its final use.
- Keep reviews small. Large changes hide problems.
- Write comments that explain the risk and suggest a fix.
- Treat review as teamwork. Critique the code, never the person.
- Track common findings and turn them into training or automated rules.
Building a Review Culture
Developers accept security feedback best when the process feels helpful. Share a short checklist, celebrate good catches, and keep a library of fixed examples from your own projects. Short training sessions on recent findings turn each review into a lesson. Over time, authors catch the same problems before reviewers ever see them.
Key Takeaways
- Code review finds flaws early and cheaply.
- Tools scan quickly, and people understand context.
- Checklists keep reviews consistent.
- Following untrusted data through the code reveals the riskiest paths.