Within the OWASP community, there are several projects related to AppSec, among them a series entitled TOP 10, which has specific subjects such as WEB, API, and Mobile.
When consulting the link related to projects on the OWASP website, we saw that this series is included in the Education theme.
Can the OWASP TOP 10 Project be used only for “Education”? This is a question that we will answer in the course of this article!
But after all, what is the OWASP TOP 10 project?
It is an awareness document for developers, representing a consensus on the most critical security risks for WEB, API, and Mobile applications.
When analyzing each risk, you will find a structured overview with description, prevention, examples of attack scenarios, and references.
The risk list varies by technology:
- WEB: A01:2021-Broken Access Control, A02:2021-Cryptographic Failures, A03:2021-Injection, A04:2021-Insecure Design, A05:2021-Security Misconfiguration, A06:2021-Vulnerable and Outdated Components, A07:2021-Identification and Authentication Failures, A08:2021-Software and Data Integrity Failures, A09:2021-Security Logging and Monitoring Failures e A10:2021-Server-Side Request Forgery;
- API: API1:2019 Broken Object Level Authorization, API2:2019 Broken User Authentication, API3:2019 Excessive Data Exposure, API4:2019 Lack of Resources & Rate Limiting, API5:2019 Broken Function Level Authorization, API6:2019 Mass Assignment, API7:2019 Security Misconfiguration, API8:2019 Injection, API9:2019 Improper Assets Management e API10:2019 Insufficient Logging & Monitoring;
- MOBILE: M1: Improper Platform Usage, M1: Improper Platform Usage, M2: Insecure Data Storage, M3: Insecure Communication, M4: Insecure Authentication, M5: Insufficient Cryptography, M6: Insecure Authorization, M7: Client Code Quality, M8: Code Tampering, M9: Reverse Engineering e M10: Extraneous Functionality.
These lists undergo constant updates, its last WEB update was carried out in 2021, the API in 2019, and the MOBILE in 2016.
Another interesting information is that the lists are originally written in English, however, it is possible to find them in other languages, of course, in this case, it depends a lot on the contributions to the project.
How to apply the OWASP TOP 10 in practice?
Consulting the OWASP TOP 10 website, it shows us a list with some recommendations. Here, we will comment on some that are on this list, but we will also comment on some coming from our experience.
- Awareness and Training
Undoubtedly the subject on which the OWASP Top 10 can best be put to good use. Even, as already mentioned, this document falls under “Education.”
It can be a rich foundation for building an application security awareness program. And to reinforce this idea, when we look at maturity level 1 of the OWASP SAMM Guidance and Education practice Training and Awareness Stream says that we should conduct training where the OWASP Top 10 should be covered even at a high level.
- Security Requirements and Threat Modeling
If you want to know more about Security Requirements and Threat Modeling, then check out Conviso’s ASVS Requirements articles on Application Security and What is Threat Modeling.
As we begin implementing security requirements, the first question that comes to mind is: “What do I want to protect myself from?” And to answer this question, we can use the OWASP Top 10. For example, I want to protect myself from the risk of “Broken Access Control,” and by accessing the information about it, you will see a list of mapped CWEs.
Now access the OWASP ASVS security requirements list and see that for each security requirement, there is a CWE column. This column is nothing more than a from/to, so by applying the X requirement, you mitigate the CWE Y and, consequently, the OWASP Top 10 risk.
Another way to get to the security requirement is to perform threat modeling, which is even more interesting than the previous one, is to think about the requirements directly because with modeling, you initially focus on the “threat/attack,” and here, the problems begin… When we are talking about developers carrying out threat modeling, it is thinking about the “threat,” thinking about the attack that the application may suffer. They usually do not have this custom this insight by nature.
To “help” with this “problem” we can use the OWASP Top 10. The logic is similar to the security requirements.
Let’s assume that you will carry out threat modeling of your login API, when consulting the OWASP Top 10 you identify that your API may suffer from the Identification and Authentication Failures risk, again we go to the list of mapped CWEs and analyze them, you identify that your API may suffer from weakness CWE-287: Improper Authentication.
This weakness leads us to some CAPEC attacks, so with that we have some threats such as CAPEC-114: Authentication Abuse, CAPEC-115: Authentication Bypass attacks, among others.
Now I have the API threats/attacks/weaknesses, and with that, I come to the security requirements that I must implement to mitigate the weaknesses/attacks/threats.
- Secure Code Review
Talking about a Code Review for a developer is “rain in the wet”. After all, this is a constant task in the life of a dev. The idea behind a code review is nothing less than “validating” what the little friend did.
So before this code goes to an official branch, a second developer validates that it agrees with the changes made.
When we talk about secure code review, the idea is the same, but with a security look, but what look is that? What should I look for?
OWASP has a code review guide that can help you. Within this guide, there is a section with a checklist, however, when you are starting with the practice of secure code review, this checklist can be too much.
An alternative could be to use the OWASP Top 10, where, instead of using the checklist in the OWASP guide, the OWASP Top 10 would be used as a checklist, so we searched our secure code reviews for possible failures related to the OWASP top 10.
- Security Test
Let’s do an exercise here, when we take the first category of risk that mostly happens in a WEB application (Broken Access Control), we have information that 94% of the tested applications had this risk affected.
Therefore, the OWASP Top 10 can be an interesting starting list for security tests, whether manual or automated.
Documentation OWASP TOP 10
OWASP Top 10 are documents with the categories of risks that most occur in applications. It is a document framed in the “education” area, but which can be used for the most diverse activities within an AppSec program, such as Security Requirements, Threat Modeling, and Secure Code Review, among many others.
