50 Point Checklist for Secure Code Review

Secure Code Review identifies possible security vulnerabilities related to features and design in the application. This process may be initiated at the beginning of the software development life cycle and continue even when the software will be in use in production.

Source Code Review is the most effective technique to eliminate security issues effectively if performs correctly. In this article, a security analyst may use 50-point checklist for auditing software applications for secure code review. We have compiled a Checklist for Secure Code Review that may be followed while performing code review.

What is Code Review and Which Tools used for it

How to perform Secure Code Review?

Effective source code review can't be done merely using tools or by human effort. This activity is a combination of both. For example, security code review tools may help identify some issues related to identifying vulnerable functions. Simultaneously, human effort is needed to identify flaws relating to business flaws and logical issues. The two-step approach may be employed for effective secure code review:

  1. SAST or Static Application Security Testing tools must scan the source code repository to identify vulnerabilities related to vulnerable functions or string patterns. DAST or Dynamic Application Security Testing must be used to identify run-time vulnerabilities such as cross-site scripting. This step helps in the coverage of application that is difficult to achieve by using only human effort.
  2. The code auditor maybe sits with the developer to understand the functionalities of the application and different directories in a source code repository. Further, SAST and DAST tool reports analyze by the code auditors and identify real vulnerabilities. Also, step 2 identifies logical and design flaws that may not be visible in step 1.

50-Point Checklist for Secure Code Review

1. Any extraneous functionality implemented in the application.
2. Any sensitive information used by the application.
3. Secrets must be accessible with proper authentication.
4. Untrusted input is not acceptable by the application. Validate user input by testing length, range, type, etc.
5. Business logic implemented in the application needs to be validated.
6. Are there any backdoors for authentication for admin users?
7. Check for default configurations like Access- ALL.
8. Data validation must be done on the server side.
9. Check the login page available only on the secure channel (over TLS).
10. Ensure error messages do not leak any information.
11. Ensure username and password are not available in logs.
12. Check password complexity is sufficient enough.
13. Check for a password expiration mechanism.
14. For critical applications, ensure multi-factor authentication enforce and strictly enabled.
15. Bruteforce preventable mechanisms (e.g., Captcha) must be employed.
16. Not allow the user to enter multiple guesses in Captcha after an incorrect attempt.
17. Ensure security checks are implemented before processing inputs.
18. Ensure PINs used as two-factor authentication have a short lifespan and are random.
19. Ensure session ID length must be at least 128 bits.
20. Ensure session cookies must be encrypted.
21. Ensure session time-out inactivity is enforced.
22. Ensure implementation of the session timeout mechanism.
23. Ensure active sessions must be warned if accessed from a different location.
24. Ensure the session elevation mechanism is correctly implemented.
25. Ensure keys or secrets not be hard coded in source code.
26. Ensure the application uses a certified implementation of cryptographic algorithms.
27. Ensure protection at rest mechanisms are implemented.
28. Implement HTTP Strict Transport Security (HSTS) for critical interfaces.
29. Ensure no proprietary algorithms are used without proper validation.
30. Source code must be properly commented on to increase readability.
31. Ensure the logging mechanism is implemented for critical functionality.
32. User and Role-based privileges must be verified thoroughly.
33. Ensure X-Frame-Options: deny implemented correctly.
34. Ensure X-XSS-Protection: 1; mode=block to mitigate XSS attack.
35. Ensure the application store password by using a suitable cryptographic mechanism.
36. Ensure notification must be triggered on the registration confirmation or forgot password functionality usage.
37. Ensure sensitive information is transmitted in encrypted form.
38. Ensure database credentials are stored in an encrypted format.
39. Ensure no components such as libraries, frameworks, etc. are updated to the latest version.
40. Ensure all redirects/forwards are based on a whitelist instead of the blacklist.
41. Ensure the same-origin policy is correctly implemented.
42. Ensure payment-related information such as credit card numbers etc. must not be logged.
43. Ensure a generic error page is implemented on application failure.
44. Ensure the application changes the logging level if it detects any attack.
45. Check how the administrator knows that the application is under attack.
46. Check for a race condition.
47. Check for a buffer overflow vulnerability.
48. Check the application enforce users to change the default password on the first login.
49. Check application use any elevated OS/system privileges for external connections/commands.
50. Check for authorization-related issues.

Click Here for Top 25 IoT Security Testing Tools


Code review is a skill that requires a lot of hard work. The more you are involved in the code review activity, the more you know the techniques involved. But if you have one checklist that helps you identify all points, it definitely enables you to do an effective code review.

Subscribe us to receive more such articles updates in your email.

If you have any questions, feel free to ask in the comments section below. Nothing gives me greater joy than helping my readers!

Disclaimer: This tutorial is for educational purpose only. Individual is solely responsible for any illegal act.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *