OWASP’s ranking for the major API security risks in 2023 has been published. The list includes many parallels with the 2019 list, some reorganizations/redefinitions, and some new concepts.
Here are the OWASP Top 10 API Security Risks of 2023 and a comparison to the 2019 version:
- The top two remain almost identical: broken object level authentication (API1) and broken authentication (was broken user authentication; API2),
- API3 is now broken object property level authorization. It used to be excessive data exposure,
- API4 changes from lack of resources & rate limiting to unrestricted resource consumption,
- API5 remains the same: broken function level authorization,
- API6 changes from mass assignment to unrestricted access to sensitive business flows,
- API7 changes from security misconfiguration to server-side request forgery,
- API8 changes from injection to security misconfiguration (down one place from 2019),
- API9 changes from improper assets management to improper inventory management,
- API 10 changes from insufficient logging & monitoring to unsafe consumption of APIs.
Neither threats nor risks change drastically over a few years; but they evolve, and our understanding of them equally evolves. This is demonstrated by the 2023 listing – not so much a new list but a refining of the existing list.
The OWASP lists are a collaborative effort. While nobody doubts their value, not everyone – not even those involved – agrees with all the details. Take the removal of excessive data exposure from API3.
“Does this mean we solved sensitive data exposure?” asks Cequence Security’s Jason Kent. “No, Sensitive Data Exposure is a huge problem. In the 2023 version of API 3 we are seeing an example of someone taking sensitive data exposure to the next step and breaking through the property level authorization. It isn’t a direct replacement because many of the items in the list depend on sensitive data exposure. Is this the right way to present it? I don’t think so, it is an example of varying opinions.”
At the same time, he praises the name change in API6 for what is fundamentally the same risk. The examples listed remain basically the same: both are for a ride share app and both exploit something in the backend. “There is something subtle about the naming that makes the 2023 one seem like something that needs to be fixed, rather than being nebulous and confusing. It also illustrates our findings on how API security that isn’t functioning properly ends up with attack automation being utilized against it.”
The main problem with creating an itemized and ordered risk list is the chain of risk. Breaches often start from an API the victim has forgotten (API9). This might provide sensitive user data (API1) prompting the attacker to create a bot to exploit the flaw as far and as fast as possible (touching on API6).
“The new API Top 10 may not be perfect,” concludes Kent, “but it does show us exactly what we have known for several years now. The landscape of API security is changing, and organizations need to change with it. Whether it is knowing where your APIs are, testing them for flaws or mitigating bots attacking your unknown flows, API security needs to be a focus for everyone – and this new list is a great place to start.”