Security code review checklist

Using a secure code review checklist helps you find security vulnerabilities systematically during code review, and is a code review best practice. With this security code review checklist, you know exactly which security flaws to look for and how to implement secure coding practices.

Table of Content:

• Popular security vulnerabilities lists
• Security vulnerabilities are often undetected
• Find security vulnerabilities systematically
• Secure code review checklist - Short version:
• Secure code review checklist - Extended version
  • Input Validation
  • Authentication and User Management
  • Authorization
  • Session Management
  • Encryption and Cryptography
  • Exception Handling
• Practice finding security flaws during code reviews
• Conclusion

Popular security vulnerabilities lists

You probably heard about the OWASP Top 10, or the CWE Top 25. OWASP Top 10 is a list of the ten most critical web application security risks, such as Injection Broken Authentication and Session Management, or Cross-Site Scripting (XSS). OWASP Top 10 are published and maintained by the OWASP (Open Web Application Security Project) community. Similarly, the CWE Top 25 is a list of the 25 most prevalent software weaknesses which the MITRE Corporation publishes and updates. In contrast to the OWASP Top 10 which focuses on web application security risks, the CWE Top 10 focuses on a broader range of software security vulnerabilities that also affect mobile and desktop applications.

Watch my video on finding security vulnerabilities and bugs that appeared on the OWASP DevSlop show to learn more about secure code reviewing.

Security vulnerabilities are often undetected

The problem is, even if you heard about both lists highlighting common security risks, and even if you studied the listed vulnerabilities, it’s unlikely you know them all by heart. As a result, during code reviews, many security vulnerabilities are overlooked by developers. Also, following the “shift left” mentality of testing and security, you do not want to wait for a dedicated security team to perform static application security testing, or to find many issues during dynamic application security testing.

A study about security aspects during code reviews confirms that developers often do not focus on security aspects during code reviews. Many developers that participated in the experiment did not find the seeded security bugs. When the researchers reminded the developers to explicitly inspect the code for security flaws, their ability to find security defects increased. Yet, the study made clear that developers still struggle with finding security issues during code reviews. The researchers state: “developers report the lack of training and security knowledge as the main challenges they face when checking for security issues.”

Find security vulnerabilities systematically

This is where secure code review checklists, also referred to as security checklists, come into play. Code review checklists are a wonderful learning and mentoring tool, and an important code review best practice. They also help you remember which issues you should focus on. Finally, with a secure code review checklist, you can inspect the code systematically for security vulnerabilities.

Reviewers using a code review checklist outperform reviewers who are not.

All three benefits of using a security-focused code review checklist help you adapt, practice and promote secure coding practices within your team. So, without further ado, let’s have a look at a secure coding checklist:

Secure code review checklist - Short version:

• What security vulnerabilities is this code susceptible to?
• Are authorization and authentication handled in the right way?
• Is (user) input validated, sanitized, and escaped to prevent cross-site scripting or SQL injection?
• Is sensitive data like user data, or credit card information securely handled and stored?
• Does this code NOT reveal some secret information like keys, passwords, or usernames?
• Is data retrieved from external APIs or libraries checked accordingly?
• Does error handling or logging NOT expose the system to vulnerabilities?
• Is the right encryption used?

Secure code review checklist - Extended version

Input Validation

• Are inputs from external sources validated?
• Is user input tested for type, length, format, and range, and by enforcing limits?
• Are flaws in regular expressions causing data validation problems?
• Are exact match approaches used?
• Are allow list approaches used (i.e., check strings for only expected values)?
• Are block list approaches used (i.e., rejected stings for inappropriate values)?
• Are XML documents validated against their schemas?
• Are string concatenations NOT used for user input?
• Are SQL statements NOT dynamically created by using user input?
• Is data validated on the server side?
• Is there a strong separation between data and commands, and data and client-side scripts?
• Is contextual escaping used when passing data to SQL, LDAP, OS and third-party commands?
• Are https headers validated for each request?

Authentication and User Management

• Are sessions handled correctly?
• Do failure messages for invalid usernames or passwords NOT leak information?
• Are invalid passwords NOT logged (which can leak sensitive password & user name combinations)?
• Are the password requirements (lengths/complexity) appropriate?
• Are invalid login attempts correctly handled with lockouts, and rate limits?
• Does the “forgot password” routine NOT leak information, and is NOT vulnerable to spamming?
• Are passwords NOT sent in plain text via email?
• Are appropriate mechanisms such as hashing, salts, and encryption used for storing passwords and usernames?

Authorization

• Are authentication and authorization the first logic executed for each request?
• Are authorization checks granular (page and directory level)?
• Is access to pages and data denied by default?
• Is re-authenticate for requests that have side effects enforced?
• Are there clear roles for authorization?
• Can authorization NOT be circumvented by parameter or cookie manipulation?

Session Management

• Are session parameters NOT passed in URLs?
• Do session cookies expire in a reasonably short time?
• Are session cookies encrypted?
• Is session data being validated?
• Is private data in cookies kept to a minimum?
• Does the application avoid excessive cookie use?
• Is the session id complex?
• Is the session storage secure?
• Does the application properly handle invalid session ids?
• Are session limits e.g., inactivity timeouts, enforced?
• Are logouts invalidating the session?
• Are session resources released when sessions are invalidated?

Encryption and Cryptography

• Are state-of-the-art encryption algorithms used (such as FIPS-140)?
• Are minimum key sizes supported?
• What types of data must be encrypted?
• Has sensitive data been secured in memory, storage and transit?
• Do restricted areas require SSL?
• Is sensitive information passed to/from non-SSL pages?

Exception Handling

• Do all methods have appropriate exceptions?
• Do error messages shown to users NOT reveal sensitive information including stack traces, or ids?
• Does the application fail securely when exceptions occur?
• Are system errors NOT shown to users?
• Are resources released and transactions rolled back when there is an error?
• Are all user or system actions are logged?
• Do we make sure that sensitive information is NOT logged (e.g. passwords)?
• Do we make sure we have logs or all important user management events (e.g. password reset)?
• Are unusual activities such as multiple login attempts logged?
• Do logs have enough detail to reconstruct events for audit purposes?

Practice finding security flaws during code reviews

To practice finding security bugs during code reviews, I prepared a small codebase for you. The codebase is in HTML, and JavaScript and uses Express. As long as you have experience developing code, I recommend reviewing the code even if you are not familiar with JavaScript.
The example codebase is small, and you should be able to find quite a few of the seeded security defects and other problems within the code. Here, you find the repository to test your secure coding practice knowledge.

Conclusion

Research is very clear on the power of code review checklists. Code reviewers who use a code review checklist outperform code reviewers that don’t. So, I hope this checklist is helpful and valuable to you and that you start boosting your code review effectiveness with it.

You can find the security code review checklist also on GitHub. And, check-out my general code review checklist that helps you focus on the most important issues during code review. Also, read about other best practices for code reviews here.