Industry Leaders Weigh in on the 2023 OWASP API Security Top 10 

The 2023 OWASP API Security Top 10 is out now — take a look! We summarized the changes below and gathered perspectives from application security pros and NetSPI partners on the biggest updates. Take a look at what changed and what industry leaders think about it.  

Notable Updates from 2023 List 

• Remains in 1st place: API1:2023 – Broken Object Level Authorization 
• Remains in 2nd place: API2:2023 – Broken Authentication 
• Remains in 5th place: API5:2023 – Broken Function Level Authorization 
• Moved from 7th to 8th place: API8:2023 – Security Misconfiguration 
• Renamed API9:2019 – Improper Assets Management to API9:2023 – Improper Inventory Management 

What fell off the list from 2019: 

• API3:2019 – Excessive Data Exposure 
• API4:2019 – Lack of Resources & Rate Limiting 
• API6:2019 – Mass Assignment 
• API8:2019 – Injection 
• API10:2019 – Insufficient Logging & Monitoring 

What’s changed on the list in 2023:  

• API3:2023 – Broken Object Property Level Authorization 
• API4:2023 – Unrestricted Resource Consumption 
• API6:2023 – Unrestricted Access to Sensitive Business Flows 
• API7:2023 – Server Side Request Forgery 
• API10:2023 – Unsafe Consumption of APIs 

Meet the Contributors

Based on these updates, we asked NetSPI partners and our Director of Application Pentesting, Paul Ryan, a few questions on the reasons behind these key themes and the importance of API security. Here’s what they said.

• Michael Yates, All Lines Technology Chief Information Security Officer 
• Larry Maccherone, Contrast Security Dev[Sec]Ops Transformation Architect 
• Mike Charobee, Cyber Buyer Founder 
• Paul Ryan, NetSPI Director, Application Pentesting 
• Josh Smith, Nuspire Cyber Threat Analyst and author of its quarterly Threat Report 
• Jamie Maxfield, VLCM Cybersecurity Solutions Architect

What conclusions can you draw from the updated list? Are there any key themes to call out?

“The common theme is all threat agents and attack vectors are at an easy exploitability level. If it’s that easy, watch out for the mass amount of bots attacking.”

– Mike Charobee, Cyber Buyer Founder

“Several vulnerabilities in the updated list are related to broken or insufficient authorization mechanisms, such as API1:2023, API3:2023 and API5:2023. This highlights the need for secure access controls at various levels throughout APIs, from the object to the functional level. API4:2023 and API6:2023 show the need for managing and restricting resources consumed by APIs. API9:2023 and API10:2023 illustrate the importance of maintaining an accurate inventory of APIs and managing third-party APIs securely.”

– Josh Smith, Cyber Threat Analyst and author of Nuspire’s quarterly Threat Report 

“Proper authorization of APIs continues to be critical as it encompasses not only the top spot again, but a full three of the top 10 categories (API1, API3, API5). The second theme is the number of ’new’ vulnerability categories. While these are not ‘net new’ per se, they do represent that the API attack surface is changing: as companies move to protect and fix areas in the 2019 Top 10, attackers continue to adapt and focus on other areas.”

– Paul Ryan, NetSPI Director, Application Pentesting 

“The changes are in direct response to the growing Digital Transformation move, as well as Containerization, and the plethora of needs APIs fulfill to meet these modernization demands. Couple this with the business pressures to adopt and implement a Digital Transformation strategy and the skills shortage in Cybersecurity, DevOps teams are completing their task either trusting the third-party API security or rushing development without adopting a security-by-design approach from the start.”

– Michael Yates, All Lines Technology Chief Information Security Officer 

“When the first version of the OWASP Top 10 API Security list came out in 2019, the thing that most struck me was how few of the items on the list were conducive to detection by automated tools. Less than half would at least partially benefit from some sort of tooling-based detection.

In the 2023 version, it’s even worse. API7 – Server-Side Request Forgery (SSRF) is the only one remaining that can be completely or almost completely addressed by traditional AST tools. API8 – Security Misconfiguration can be partially addressed by emerging infrastructure as code (IaC) security tools, and there are tools that will help with API9 – Improper Inventory Management, which may be more recognizable as ‘shadow APIs.’  

The rest are nearly impossible to automatically detect with automation because the design intent of the developer is a factor in all of them and, putting AI aside for a moment, determination of intent is not conducive to automation. Design and engineering excellence complemented by pentesting and threat modeling (all heavy on human effort) are how you address them.”

– Larry Maccherone, Contrast Security Dev[Sec]Ops Transformation Architect 

There are FIVE new vulnerabilities on the list, why do you think these have become more prevalent? 

“Lack of resource and rate limiting (2019) has been renamed and separated to become API4 and API10; but throttling limits continue to be overlooked in API security. Also, API10 in particular is interesting as it represents how applications are very rarely siloed. Vulnerabilities in APIs can have both north-south and east-west effects that impact other interconnected systems which consume them.”

– Paul Ryan, NetSPI Director, Application Pentesting 

“Here are a few thoughts I have. But take it like opinions on music. There is a little bit of country and a lot of rock and roll.  

• API2:2023 – Broken Authentication: This one is a no brainer. Authentication is the gold standard of security. You have to be able at a baseline level to know who, what, when, and how someone accesses anything. Many times, developers, security analysts, IT admin, and so on are not keeping authentication tokens updated and managed properly. This leads to temporary or permanent identification takeover.  
• API4:2023 – Unrestricted Resource Consumption: This is like allowing my kids to have as much ice cream as they want. Or at least until the ice cream runs out. Leaving me with no ice cream when I need it at 2 am. You do not want to see me with no ice cream at 2 am. APIs are processes. Processes need resources. Memory, CPU, Bandwidth, and Storage. Unchecked resource requests can overrun your APIs causing systems to crash. Crashed systems cost money and loss of revenue which is not a good combination. It can also lead to denial-of-service attacks.  
• API7:2023 – Server Side Request Forgery: The old “Switch-A-Roo”. API request that doesn’t ask for or check the returning URI. Allowing a change of address. This can also bypass firewalls and VPNs as most are not configured to check for malicious URI via API.  My kids used to do this with their Christmas presents sometimes. Move a name tag from one gift to another in hopes that they get the new Nintendo switch and not a box of tighty-whities.  
• API10:2023 – Unsafe Consumption of APIs: This might be one of the most important areas for the DevOps and InfoSec teams to communicate. You might have tight security with your APIs, but you must demand that same of the APIs you are interacting with. Developers, develop. It’s in their name. It’s their nature. It’s what they do. One of the most creative, efficient, and trusting groups of people you will ever meet. Sometimes too trusting. It’s exciting to hook up with a new API. It looks good. It swiped on you; you swiped back. Now let’s meet for coffee. Then the API shows up. Clearly using a different photo. But now you are there paying for their coffee. What’s the old Ronald Reagon quote? Trust but verify. That needs to be tattooed on anyone who develops APIs.  

I encourage all my DevOps and InfoSec friends to go give this a read. More information is available on the official website. Not as fun to read, but more technical with information that may keep your company, your team, and you out of the news.” 

– Jamie Maxfield, VLCM Cybersecurity Solutions Architect 

“These new vulnerabilities reflect the shifts in the threat landscape and emerging preferred/new attack vectors. Increases in automation and digitization have spurred surges in API usage worldwide. When not properly managed, APIs can become an attack vector for things such as denial of service attacks (API4:2023), misuse of functionalities (API6:2023), exploitation of weaknesses in the way APIs interact with services (API7:2023) and vulnerabilities from third-party integrations (API10:2023). And properly managing APIs is easier said than done, given how many exist today and the number of versions for each one (API9:2023). These are real threats affecting organizations, and due to their challenges and severity, OWASP has included them within this list.”

– Josh Smith, Cyber Threat Analyst and author of Nuspire’s quarterly Threat Report. 

“I only consider one and a half of them as truly “new.” API7: 2023 replaces API8: 2019 and API10: 2023 replaces API10: 2019. The other three are merely wording refinements, or, in the case of API3: 2023, a merging of two from the 2019 list. There was a release candidate in March 2023 that showed five as “new” but there were changes made before the final, driven by sharp feedback against the release candidate, and some of those that were labeled as “new” were essentially refinements of a roughly equivalent item from the 2019 list. 

As I said, most of the difference is refinement in wording and scope.

Let’s discuss those one and a half that are ‘new’ one at a time: 

• The half-new. API7:2023 – Server-Side Request Forgery (SSRF) replaces API8:2019 – Injection flaws. The relative incidence of vulnerabilities of these two types have not changed much from 2019 to 2023 so I assume this change is mostly driven by an increase in the volume of attacks we’re seeing against SSRF vulnerabilities. SSRF attacks are newer than injection attacks and it has taken a while for attackers to understand how to exploit. This also makes sense as more container-based systems come online. 
• I see this is only ‘half new’ because the committee seemed to think that ‘Injection is now essentially part of API7:2023 – Security Misconfiguration’. That’s a huge stretch. While a small portion of injection attacks can be prevented with configuration changes, injection attacks are much more a function of code than configuration.
• The full-new. API10:2023 – Unsafe Consumption of APIs replaces API10:2019 – Insufficient Logging & Monitoring. You would expect changes to occur at the bottom of the list and we don’t know if API10:2019 moved down to #11 or #111 so this is not a dramatic change.” 

– Larry Maccherone, Contrast Security Dev[Sec]Ops Transformation Architect 

What factors are impacting these changes? 

“With the increasing use of APIs, more vulnerabilities emerge. API interactions are becoming more and more complex, allowing potential misconfigurations, inventory management issues and third-party risk from third-party service APIs.”  

– Josh Smith, Cyber Threat Analyst and author of Nuspire’s quarterly Threat Report 

“Not enough time to thoroughly investigate these threats and their tasks need to be persistently checked.” 

– Mike Charobee, Cyber Buyer Founder 

“The demand for more complex and more interconnected information systems as well as tailor-made data sets are requiring development teams to expose APIs to their applications and data. Along with this demand is the requirement to build, maintain, and (usually as an afterthought) protect these APIs. The changes seen in the Top 10 are due to a combination of more available APIs and a lack of resources or awareness to protect them.”

– Paul Ryan, NetSPI Director, Application Pentesting 

“Refinement of wording and scope is the primary factor of change. Not all of that refinement has gone in the right direction though as I don’t see how Inject attacks can be considered mostly covered by Security Misconfiguration.” 

– Larry Maccherone, Contrast Security Dev[Sec]Ops Transformation Architect 

Why is API security important? What’s the risk of an insecure API? 

“API security is crucial to an organization’s cybersecurity posture because these APIs act as a gateway to an organization’s data and services. An insecure API can lead to the exposure of sensitive data and data breaches. It could allow unauthorized access to critical business functionalities, causing misuse or disruption of services. APIs also could provide a threat actor initial access into a network to carry out further attacks. With how interconnected organizations are, an insecure API could put a single organization at risk and the organizations they interact with. API attacks could lead to loss of data, damage to a company’s reputation, financial loss and loss of customer trust.”

– Josh Smith, Cyber Threat Analyst and author of Nuspire’s quarterly Threat Report 

“The majority of businesses never check their API security. ‘Don’t expect what you don’t expect.’”

– Mike Charobee, Cyber Buyer Founder 

“APIs act as gateways to the functions and data within an organization; they need to be protected with the same level of rigor as other applications or database systems. Like application security, cloud security, and mobile security, organizations need to recognize the importance of API security in their overall security program. Not validating the security of APIs leaves the gate open to attackers to try to exploit any of the previous or “new” Top 10.

– Paul Ryan, NetSPI Director, Application Pentesting 

“API security enables the protection of the availability, integrity, and confidentiality of the business-critical applications and sensitive data the API was designed to communicate. Not only the company data but also third-party data is at risk. Given the rise of cyber-attacks, whether criminal or nation-state, and the explosion of API use, the risk of an incident or breach is imminent unless DevOps standards include the design, implementation, and continuous monitoring and maintenance of API security.”

– Michael Yates, All Lines Technology Chief Information Security Officer 

“Most people think of applications from the perspective of the UI. However, all those UIs speak through APIs to where the real risk resides, on the server or in the cloud. This is not news to application security experts and tooling vendors. The vast majority of what every application security vendor does is at the API level.

So, while it’s hip to think of API Security as a new category, it’s not.  

You do more to protect your application by focusing on traditional application security. All of the so-called API Security Top 10 items, with one exception, are best addressed with traditional application security thinking (threat modeling, pen testing, AST tools, etc.).

The one exception is shadow APIs (aka API9:2023 – Improper Inventory Management). These are APIs that your development teams are putting out there that security has no prior knowledge of. There are specialist tools, and free alternatives, that will help you discover these. Those same API specialist tools also attempt to do things that more established AST tool vendors do but they are a generation behind, so you are better off not using them.  

Also, as an established application security tool vendor, we’re not sitting idly by. We’re working on major functionality right now that will help address not just shadow APIs but other ways in which the applications your organization has built behave differently than you expected.”

– Larry Maccherone, Contrast Security Dev[Sec]Ops Transformation Architect 

Reliance on APIs is only going to continue, making the security of those APIs a prime area to focus. Inventorying APIs and evaluating them against the OWASP API Security Top 10 is a lot easier with the right partner clearing your way. Take a look at NetSPI’s API penetration testing services and get in touch with us for a quote.

This post was written in collaboration with NetSPI’s Partners. Learn more about becoming a NetSPI partner here.