How to use TODO comments for secure software development

If security controls are disabled, they must be reactivated

Consider this simple example: A client requests a new search function to provide immediate feedback to its users when they are looking for particular documents on the company's website. The requirement is that the search results update as a user types in a document title, filtering the results each time a character is entered. Most importantly, the list of documents returned by the search should only include those that users can access based on their type of membership and access.

To work as requested, this new feature requires two things: first, to validate that any search request is coming from a valid user -- authentication control -- and second, that the database query only returns records of documents that the user is allowed to access -- access control. These security controls should be implemented at the beginning of the development of the new feature in a DevSecOps environment. This means the developer needs to register a dummy test account, assign different membership types and log in repeatedly in order to test whether the code for the search function and the security controls work as expected.

Most developers, however, will split this task into two parts: first, creating a new search feature and then ensuring it only returns results based on the user's membership type, not a new search feature that should only return results based on the user's membership type -- a subtle but important difference in how security gets implemented.

In reality, 99 times out of 100, developers will dispense the dummy test account and leave out the required security checks so they know any errors or unexpected search results are solely down to the search-related code and not connected in any way to authentication and access controls blocking requests. This makes it quicker and easier to isolate problems. Even those developers who do add in the required security checks as part of the initial build will often also disable them at some point to speed up testing and bug fixing.

Once the search feature is working, the developer will -- hopefully -- add or reenable the necessary authentication and access checks and carry out further testing to ensure only logged-in users can access and use the new search and any results only show documents the users are allowed to see.

Alas, security cannot rely on hope. Often, security controls are buried in middleware, gateway or request routing code, making it tricky to find and reactivate each control.

Although the above is a simplified example, there are too many real-world examples where developers have failed to implement and test the required security controls or failed to reactivate them once development and testing have been completed, leaving applications, their users and the companies operating them at risk.

How to use TODO comments to reactive security controls

Secure software development is a no-brainer. However, as illustrated above, security controls can be difficult to find and reactivate. Fortunately, there are some preemptive steps developers can take to make the burden easy to implement -- and remember.

Feature request documentation is important as it records which security controls are required to ensure the correct authentication and access checks are implemented. These should be added to each developer's to-do list, along with any other request, such as style or font. To enforce feature request documentation use, developers should not be allowed to ever push code from development to production while there are still items on their to-do list. Most integrated development environments include features or have plugins that will search an entire code base and flag files that contain keywords such as TODO or FIXME. This quick and easy check should be performed before any code is submitted for review to ensure incomplete code is not added to the main code base.

Consider, for example, if developers add TODO comments to all unfinished code or a FIXME comment whenever they disable a security control along with a comment, such as "FIXME: Reenable access control in UserController.php line 45 and AuthenticateMiddleware.php line 82." When this keyword gets flagged, everyone involved in the software development process will know which controls need to be reactivated before the next round of updates can be pushed to production. This prevents not only a new feature from being committed that is not secure, but also safeguards other controls that rely on the same code for their security checks.

Meeting delivery deadlines in a fast-moving development environment is tough, and security is one aspect that tends to get sidelined when the pressure is on. The simple reminders listed here, although not especially sophisticated, are an easy way to ensure all the necessary security controls are in place and make it from development through to production.