The Open Web Application Security Project (OWASP) Top 10 is a ranking of the most critical security risks to web applications. It was first created as an awareness document, with the objective of motivating software developers to produce more secure code. Today, its importance is so huge that it's considered a requirements document when it comes to web application security.
This year's new installment is the result of applying a new methodology and name changes, merging categories and finding new ones. Most importantly, it has revealed a new order that highlights different issues, like secure design and threat modeling.
New times call for new ways
This year's Top 10 is based on a massive amount of data provided by different sources since 2017. The sources were as varied as organizations doing internal testing, organizations that test vendors by trade and bug bounty vendors. But, in a refreshing way, this installment now acknowledges the importance of the input provided by application security and development experts. The reason is that they have proven to be aware of trends that are not in the data produced by automated tools. These trends may be found only with new creative ways of testing, which take time to integrate into tools and processes. So, leaving the expert's account out of the list may result in an outdated ranking, which is not the point of the Top 10 at all. With this reason in mind, two of the categories in the list came from the results of a community survey asking experts what they see as essential weaknesses that may not yet be found in the data.
Like in 2017, the new installment used data that was collected and analyzed along the lines of incidence rate. This means that instead of counting every time a vulnerability shows up in a single application, it would only be counted as one. This seems to resolve the problem that some vulnerabilities that appear a ton of times in automated tools obscure the importance of some other serious vulnerabilities. Additionally, in 2021, a change in data collection was made, so that organizations could provide more data on Common Weakness Enumerations (CWEs), that is, categories of unknown custom weaknesses. Instead of being provided a restricted list of CWE categories to report, organizations were able to report any new weaknesses without restrictions.
Another noticeable difference is the change in some categories' names. These changes mirror an increased interest in the root cause as opposed to the symptoms. The rationale behind this is that, by conceding more visibility to the root causes, more attention can be directed to identification and remediation.
A new order
The new Top 10 shows how, as technology and development styles evolve, risks have increased or decreased. In a worryingly impressive climb to the first place from its previous spot at number five, Broken Access Control is the riskiest security flaw. This means that developers are failing to implement proper access control and test its functionality. The situation is not pretty, with the worsening of the next category, Cryptographic Failures, previously known as Sensitive Data Exposure, its consequence. It shows that more effort should be put into identifying sensitive information and protecting it with up-to-date encryption techniques.
Although Injection had its thunder stolen by the previous two, it is still extremely problematic. It has many faces, which have been recognized in previous installments of the Top 10. It had been number one for a whole decade and now even includes Cross-Site Scripting. The risk of Injection persists as developers still use interpreters, where the mixing of code and data is very common and results in vulnerabilities.
The highest-ranking of this year's new additions is Insecure Design, in fourth place. It refers to the lack of security controls to defend against attacks and failure to establish a secure development lifecycle. This flaw should not be taken lightly. There is a huge overlap with higher rated risks, like Broken Access Control and Cryptographic Failures, and some that are not so high up, like Identification and Authentication Failures. These risks are part of an insecure design. This means that now, more than ever, implementing secure design is not an option; it's a must. What developers should achieve is, following OWASP's recommendation, "a culture and methodology that constantly evaluates threats and ensures that code is robustly designed and tested to prevent known attack methods." This calls for the importance of threat modeling, defined by OWASP as "a view of the application and its environment through the lens of security."
Moving down the list, Security Misconfiguration went up one place and appears merged with the XML External Entities (XXE) improper restriction issue, which is also considered a problem of configuration. This and the following category, Vulnerable and Outdated Components, which moved up several places and had its name revamped, remind us of the growing importance of properly configuring and upgrading the application's components, while also defending against attacks where there are known vulnerabilities.
Number seven, Identification and Authentication Failures, previously known only as Broken Authentication, poses at least a redeeming quality of development over the last years. Namely, that this category's dramatic drop from second place means that the problem is being tackled, perhaps through growing implementation of multi-factor authentication, password complexity, limited failed login attempts, among others.
Another new addition, at number eight, seems to be motivated by the appalling impact of the SolarWinds security fiasco. The risk of Software and Data Integrity Failures urges developers to verify integrity in the entire software build chain. This not only means that the components used to build the applications should come from trusted sources and be digitally signed. It also means that attention should be directed to how suppliers are managing their supply chain to provide integrity to their software. The merging of Insecure Deserialization with this category stresses the importance of also ensuring data integrity by validating almost every bit of data.
At number nine, Security Logging and Monitoring Failures had a subtle name change and moved up one place. This category was also supported by the results from the community survey. It reminds us of the importance of implementing run-time protection to detect attacks and create visibility into who is attacking, which, again, brings us back to secure design.
The last new addition, at number 10, comes mainly from the community survey. Experts are trying to raise awareness that Server-Side Request Forgery (SSRF) is a thing. It happens when there is no proper validation of the user-supplied URL, which allows the attacker to make the application send a crafted request to an unsuspecting destination.
That is the end of the list. Now, are you ready to tackle the challenge ahead? At Fluid Attacks, we help you with OWASP compliance by implementing security at the development stage of your web applications. Contact us!
Recommended blog posts
You might be interested in the following related posts.
Watch out for keylogging/keyloggers
There's not an only way but here's a good one
Benefits and risks of these increasingly used programs
A hacker's view of the performance of Researcher CNAs
Why so many are switching to Rust
Description and critique of CEH certifications
An OffSec Experienced Pentester review
Or what makes the ethical hacker