What’s new in the OWASP Proactive Controls for 2024

I have taught a number of application security classes to developers. When it comes to vulnerabilities, there's a sort of knowledge triad:

How does the vulnerability occur? Mechanically, how does it work?

Why is it dangerous? And how much damage does it have the potential to cause?

What should be done to avoid or remove it? 

In my experience, security professionals often miss one of the three parts of that triad when explaining a vulnerability to software developers and other builders.

OWASP Top 10 Proactive Controls

OWASP's most well-known project is the OWASP Top 10, which promises to be a regularly updated list of the most prolific and dangerous web app vulnerabilities. It does well in addressing the How and Why of the vulnerabilities, but doesn’t focus as much on What to do about them. For the uninitiated, OWASP has a broad array of other Top 10 lists, including some targeting mobile and API vulnerabilities. Each of these are individual projects with their own contributors and maintainers. My favorite of the OWASP Top 10 lists is the Top 10 Proactive Controls, which I referenced in my previous series on Security Considerations when building a new Web App. Where many of the others list vulnerabilities that can occur, the Proactive Controls list identifies actions and practices to take when building software in order to avoid creating these vulnerabilities. In other words, it leads with the action item for architects and developers. Thanks to the hard work of numerous contributors, we have a new release of the Top 10 Proactive Controls this year, the previous version being from 2018. I will go through the changes briefly and share some of my own thoughts on them.

C1 - Implement Access Control

Right out of the gate, this addresses authorization. If we look at the top 10 vulnerabilities (2021 edition), Broken Access Control tops the list there too. In my view this is absolutely the best choice to put front and center. Web applications today have a lot of security by default, but access control tends to have enough business logic behind it that some manual implementation is inevitable. A catastrophic risk can easily arise from failing to correctly enforce authorization. The 2018 version had Enforce Access Controls way down the list in place number 7. I definitely see this as a great change.

C2 - Use Cryptography the proper way

This inclusion covers protection of a broad range of data, including application secrets (e.g. Database connection passwords), password storage such as for user passwords, data encryption at rest, signing keys for JWTs, and more. In a way, it combines elements of the 2018 (C3) Secure Database Access and (C8) Protect Data Everywhere items, along with specifically addressing a number of cases that have become increasingly common, the aforementioned JWT signing being a prime example. I see this as a fairly important inclusion, but it may be trying to combine too much into a single item. It just doesn't seem very focused or cohesive. One thing I think it does well is simplifying the discussion of cryptographic functions, to make it more accessible to developers that may not have had to deal with PKI. To summarize this one, I think it's a really great inclusion, but I'm not in love with how it is presented.

C3 - Validate all Input & Handle Exceptions

This is great advice about a core aspect in writing any application. It combines the 2018 list's (C5) Validate All Inputs and (C10) Handle all errors and exceptions. I found the guidance written for this one to be quite good. There are small things I would change, such as a harsher condemnation of using the denylist approach to input validation, but overall I think this one presents the right amount of detail in a very clear and readable way.

C4 - Address Security from the Start

This one incorporates the 2018 (C1) Define Security Requirements in a way, but it's more of a replacement than a direct analog. It clearly presents some great high-level philosophies to follow when designing secure software. For me, this one currently feels a bit thin. There's more that can be done to enhance this one with some discussion of where and how to incorporate security into the SDLC, perhaps making reference to OWASP SAMM's business functions and practices, especially around Design, Implementation, and Verification. I also would have liked to see this one further up the list, maybe in the number 2 or 3 spot, but in its current form I can see why it isn't. It is still worth a look, but I hope it gets some love in the form of a minor revision that builds more on it.

C5 - Secure By Default Configurations

This is another one that is fairly concise, but it covers the important parts for most software projects. My inclination would have been to word it as Use Secure Configurations, and then handle the preference for Secure-by-Default within that, while being more direct about addressing that: 

1. It is not always within your scope of control whether everything can be made secure by default. When it is not, you need to compensate. For example, if your application deployment involves setting up an instance of a vendor service that uses a default password, you can't make it Secure-By-Default, but you must change the password.
2. Secure-by-Default can sometimes be hardened further for your usage. When it can, you should prefer to do so.

Even though I'm being critical of it, the advice that is there is excellent, especially for anyone building applications that integrate with cloud services.

C6 - Keep your Components Secure

This one is fantastic, top-to-bottom. It addresses the use of third-party dependencies, and their potential for vulnerabilities and supply-chain attacks. The mitigation strategies are covered in appropriate detail for this type of list. If my team worked in a physical space, I would print the Best Practices section in a large font and post it on the wall.

C7 - Implement Digital Identity

The same heading existed in the 2018 version in the C6 position. Much of it is the same, but it remains a solid guide to authentication and session-management considerations. I spotted a few areas where this could use additional updates, such as its discussion of the SameSite cookie attribute, where the 2018 text is still present but doesn't reflect the current state of technology. Samesite is widely supported across modern browsers, and default behavior when not specified has changed on some of them. Even with the little bit of dated verbiage, this is still a worthwhile inclusion. If I were updating it, I would probably want to include discussion of using 3rd party auth providers like Okta or AWS Cognito, SAML-based SSO, and OpenID Connect. It also feels like WebAuthn could fit within this section.

C8 - Leverage Browser Security Features

I was glad to see this item in the list. The guidance is well-targeted, if a bit sparse, but the Tools and References lists they compiled for this one are awesome. Every web app developer should be familiar with everything referenced in this one. I think it's fine in the 8th spot on the list, but it's also a great topic and a smart inclusion here.

C9 - Implement Security Logging and Monitoring

This was also in the same position on the 2018 list. It's an important topic that is still covered well in 2024. There's not much more to say about it.

C10 - Stop Server Side Request Forgery

This one felt like a bit of a weird inclusion to me. I think the heading immediately feels out-of-place, because it's specifically about preventing a particular class of vulnerability. Why not have an entry for Stop Cross-Site Scripting? Because it's covered by C3 - Validate all Input & Handle Exceptions. I would argue that C3, C4, and C5 all address elements of SSRF. As a matter of fact, the first of three items listed as ways of preventing SSRF is Input validation. To me, this seems like an item that didn't need to be separated out in this list. Handling it within the other items would free up a spot that could be used for something else such as splitting the C2 Cryptography item into two more focused areas. I also recognize that the team working on this has a difficult task in terms of where to draw lines, because there is a ton of overlap between topics.

Final Thoughts 

Even though I've expressed some criticism of the new version, I believe it's a meaningful improvement over the 2018 version (and I was already a fan of the 2018 version). The project team has done a fantastic job pulling together some great guidance and resources. There are a few areas that I hope they iterate on a bit, but I would definitely make 2024’s Top 10 Proactive Controls recommended reading for experienced developers that are being asked to think more about security as part of their day-to-day responsibilities.