Application Security Code Reviews: Best Practices

Secure code reviews are an essential part of the software development life cycle (SDLC). By employing a series of security audit methodologies, you are able to proactively identify vulnerabilities or errors in an application. 

During the development of your software application, did you consider the current OWASP Top 10 web application security risks? How often do you review the CWE Top 25 Most Dangerous Software Weaknesses?

Core Review Starts With a Checklist

Intended to improve source code quality, manual code review is the first step of the software quality assurance process and can be used to check for security weaknesses and vulnerabilities. 

Code review checklists help to ensure consistent and comprehensive reviews. Rather than simply provide a list of tasks to complete, these important tools relay a series of questions that need to be asked and answered by confirming functionality, formatting, and validation.

Checklist Elements

Not all systems have the same concerns. Every organization has to decide where they are most vulnerable, and how in-depth to make their application security code review. 

To assist with the development of your own checklist, consider the following categories and questions as a jumping off point to get you started:

Structure and Logic

• Does your code pass all unit, integration, and system tests?
• Have you checked for spelling errors?
• Are code comments concise, meaningful, and devoid of secrets such as passwords or keys?
• Does your error handling or logging provide hackers with directory structure clues such as “file not found” or security tells like “access denied”?
• Has the use of external libraries, APIs, and other third-party components been well documented? Is it clear where each one has been implemented and what functionality is being utilized?
• Is the right encryption used where necessary and appropriate?
• Have you reviewed the application from all points of entry, using all authorization levels and roles?

Security

• Are authorization checks granular (per page, directory, action, etc.)?
• Is sensitive data (like user details and credit card information) stored safely and securely?
• Does your application adhere to current storage and retention legislation for all data?
• Are login attempts tracked by IP address without regard for a specific user, ensuring your system is not vulnerable to password spraying brute-force attacks that cycle through multiple user accounts with a single password?
• Have you confirmed credentials or tokens are never stored as variables or constants within your source code?
• Is session length controlled to prevent session hijacking when a user is distracted or walks away from their computer or device? 
• Have you checked to be sure session tokens are not passed in URLs?
• Have you confirmed that your password policies are about more than just strong passwords?
  • Does your organization follow NIST guidelines for password length and complexity?
  • Have you confirmed that passwords are never stored in cleartext?
  • Have you implemented hashing to transform passwords into new strings that cannot be reverted?

Input Validation

• Are all inputs from external sources validated?
• Is the data being entered into all fields being validated against constraints such as type, length, and format?
• When input data fails validation, is the user presented with a meaningful error that doesn’t divulge sensitive information?
• Are any uploaded files checked for content type, size, file type, and filename?
• Are any XML documents validated against their schema?
• Are parameterized statements being used to protect against SQL injection attacks?

Post-Implementation Considerations

• Can this code or solution be simplified?
• Is there a framework, library, service, or API that should be utilized but hasn’t been?
• Is the code readable and maintainable?
• Are there concerns regarding the compile-time or run-time dependencies?
• Has existing functionality within the codebase been re-used where possible?
• Does the application provide enough logging and debugging information to facilitate future patches and bug fixes?
• Are development, test, and production codebases properly segregated?

Also read: Best Practices for Application Security

Making Manual Code Review Easier

Understanding and reviewing source code can be made easier by implementing code formatting and architecture standards.

• Choose a naming convention and stick with it.
  • A few options include: snake_case, PascalCase, and camelCase.
• Create variables that describe their function.
  • It will be a lot easier to skim code looking at variables like userName and userAge instead of trying to decipher UN and UA.
• Functions and Classes should have descriptive titles that can be easily distinguished from each other. 
• Use consistent alignment, proper white space, and keep code-block start and end points easily identifiable.
• Code comments should be considered mandatory and kept brief.
  • As a rule, if it can go without saying… don’t say it. Nothing is less helpful or more commonly seen than a code comment that says some version of: “Now we process some stuff.”
• Separation of concerns dictates that an application should be divided into distinct sections.
  • This architecture principle will look different depending on your underlying technologies and infrastructure, but the basic idea is not to write your program as one solid block. This separation makes the purpose of code easier to identify and evaluate, allows for less duplication, and creates a more stable end product. 

Also read: Enterprise End-to-End Encryption is on the Rise

Using Automated Code Review 

Manual code provides the opportunity for human reviewers, with subject matter expertise, to evaluate the real risks and relevance of code weaknesses and vulnerabilities. This manual process also allows for errors in business logic to be identified, and can ensure that the functionality of the application adheres to the particular project specifications and requirements. 

Unfortunately, manual code review is also time consuming and subject to human error. In addition, it can be difficult to find experts who are highly knowledgeable in both security and application development. 

Given these realities, effective security code reviews use a combination of manual and automated processes. The investment into a manual security code review is best made prior to the initial launch of a new application, or ahead of a major update or upgrade; this is when the source code is new or changed. In between projects, consider employing automated tools as a supplement to these activities.

When considering automated security code review products and services, keep the following strengths and weaknesses in mind.

Strengths

• Automated security code reviews can be run frequently, with little consequence to project timelines or system resources. 
• Because automated tools are configured with a predefined set of rules, they can easily identify common vulnerabilities that are difficult to find when reviewing back-end source code such as SQL injection flaws or buffer overflows.

Weaknesses

• Your organization may require more than one automated tool to review applications with multiple components (desktop, web, and mobile applications). 
• Automated tools can lack context and are unable to take into account developer decisions and requisite business logic. It is important to keep these things in mind when interpreting the results of an automated code review as high numbers of false positives are likely.

Evaluating Compliance Risks

Part of security code reviews is ensuring that your project adheres to the compliance standards required by the various legislative bodies and industry standards organizations you may be accountable to.

Some compliance mandates you may need to accommodate include:

Security Code Reviews Protect Your Data and Systems

Security code reviews can be more than a little overwhelming, and difficult to do well. Ideally, organizations should begin security code reviews at the beginning of the SDLC and treat it as an ongoing and iterative process. If you are looking for somewhere to start, focus on the areas of code that deal with user input as these provide the most logical entry points for hackers.

Read next: Top Automation Testing Tools for Software Performance