While everyone’s busy making their lists and hoping the big man in the red suit overlooks their indiscretions and brings them something nice, I’ve been checking over a different kind of list. I’ve checked it at least twice, trying to find out what are the top risks to API Security. That list is the brand new OWASP API Security Top 10 RC1. Yes, it’s another security list of top vulnerabilities but this time it’s aimed directly at APIs.
Announced around September of this year, it’s currently set as a release candidate and I think this has the real potential of making an impact. However, you’d have to question whether we’re now entering a realm of list apathy with The OWASP Top 10, The OWASP Mobile Top 10, SANS 25, etc. Is the security community being a bit too greedy here and asking too much this year? Bearing in mind the OWASP Top 10 was designed so that organizations could easily consume it. Now when an organization is building an application, they potentially have not just one, but three Top 10 lists from OWASP alone to digest.
However, this was coming and the rumblings could be seen around the last iteration of the OWASP Top 10 RC1 which contained A10 – Unprotected APIs. Just when it looked like it was going to make it onto the coveted OWASP Top 10 it was yanked due to feedback from the community which you can see here. Basically, it was argued that APIs could be vulnerable to the risks found on the OWASP Top 10 so it didn’t need a section. Fast forward to 2019 and Erez Yalon & Inon Shkedy not only wanted a place on the OWASP Top 10 they wanted their own list.
Top risks to API Security
So, the two guys sat down and started to make their list and justified why they wanted a ’54 convertible, light blue… sorry Broken Object Level Authorization on a list of the top risks to APIs. Why it couldn’t just appear on the OWASP Top 10 list? Well first off, the OWASP Top 10 is a list of top 10 vulnerabilities for web applications and includes things like injection, XSS, CSRF, broken access control etc. The authors of the top 10 API security list felt that the “traditional” web application had different priorities to that of APIs. I’d tend to agree with this where API based applications differ enough to constitute a separate list. It’s probably about time too with the prevalence of APIs across the industry from north-south and east-west being rolled out across the enterprise. The security community responded by shining a light on the risks to APIs and having its own list makes more sense than shoving it into the OWASP Top 10. Essentially the guys put forward that API based applications are different enough that vulnerabilities for traditional web applications become less common in API based applications. Here’s the summary from the authors;
- The server is used more as a proxy for data
- The rendering component is the client, not the server
- Clients consume raw data
- APIs expose the underlying implementation of the app
- The user’s state is usually maintained and monitored by the client
- More parameters are sent in each HTTP request (object ID’s, filters)
- The REST API standard
- Standardized & generic
- Predictable entry points
- One entry point (URL) can be used for multiple purposes
- Traditional vulnerabilities are less common in API-Based apps
A different game
So, let’s unwrap this, although familiar in its format the API Security Top 10 has some different rules to it because with an API-based architecture the logic shifts from the backend to the frontend. So, the focus on the risk must shift too. The old game was dealing with the “traditional” web applications that do the processing on the server-side sending back a nicely formatted response e.g. HTML. But now we’ve got an API based application where the server simply returns the raw data and the client does the processing and parsing. From API based applications emerge single-page applications, microservices, mobile apps, IoT, etc. Another key difference is there can be fewer abstraction layers as all three elements in the architecture, client, server, and DB, speak the same language usually JSON. Also being based on the representational state transfer (REST) architectural style means APIs are standardized, generic, and predictable so there are rarely any surprises that you can get with “traditional applications.”
READ MORE: API Security–A Primer
The ace is low(er)
Now if you’re using a list of ten vulnerabilities to mitigate against security issues in your SDLC you’d be mistaken for thinking the list was complete. Lists exist for the sole purpose of highlighting the top risks. They’re great starting points but in no way are they stopping points. Just take a look at the number of CWEs which are in their thousands. So, this API Security list is not really saying that threats are different than traditional web applications but rather we’re simply playing at a different game, so the cards need to be reevaluated and re-prioritized. We haven’t changed the threat landscape but rather changed the ranking system and brought some cards out of oblivion. If we continued to play by the OWASP Top 10 it could mean product teams lose focus on what are the biggest risks as they build an API based application. So, we’ve got to look at the rules for the OWASP API Security Top 10. For instance, the ace has always been high in every iteration of OWASP Top 10. This of course is injection. However, in the API Security Top 10 this ace moves all the way down to number eight on the list. Other notable changes are CSRF which is less common because of the use of authorization headers instead of cookies. If you’re building a pure API based app you also won’t suffer client-side vulnerabilities like XSS.
The rules could change
You should bear in mind that the OWASP API Security Top 10 is a release client. It is, however, in my opinion in a good state and you should look to it but if you do feel like changes need to be made OWASP is an open community and you can submit your feedback to the project. I think the main take away from the API Security Top 10 is when developing an API based application the top risks change where some lose precedence, others become more important, some disappear, and others crawl their way up from the enormous list of vulnerabilities that don’t generally feature on the OWASP Top 10. The main focus should rightly shift from injection to AuthZ and AuthN. Client-side issues and issues around the traditional session being held by a cookie become irreverent or the risk is reduced and essentially The OWASP Top 10 and the API Security Top 10 are different beasts.
What’s next
I’ll be keeping a close eye on the project but since we didn’t go through each of the risks that appear on the OWASP API Security Top 10 in this blog post I’ll have a follow-up. As we all countdown the days from a partridge in a pear tree to the drummers drumming, I’ll look at the ten risks to API Security counting down from ten to one analyzing each one.
Learn more about OWASP API Security.