The OWASP API Security Top 10 From a Real-World Perspective

The OWASP API Security Top 10 (December 2019) highlights how APIs have become the target du jour for attackers. As someone who is both a longstanding OWASP member and who works at a company that sees attacks against customers’ APIs daily, I think publishing this was a significant first step.

It’s not uncommon that, within hours of a customer launching a mobile application, we start to see attempts against parts of the platform that aren’t exposed anywhere but in the application communication.

It makes sense–mobile applications are API-driven, and APIs make it easier to execute automated attacks of all types such as account takeovers, fake account creation, or even generating gift card numbers to validate a balance. Recently, the CQ Prime Threat Research Team published that 98% of the account takeover traffic originating from Bulletproof Proxy networks target these mobile APIs.

Thoughts on the OWASP API Security Top 10

I wanted to share how each category in the OWASP Top 10 applies to real attacks we see and also wanted to provide some thoughts on a list that might align more closely with what our team and customers deal with daily.

To clarify, our goal isn’t to say that the OWASP Top 10 list is bad, it isn’t. It’s a great start. What we are trying to convey is that rarely is a security incident caused by a lone issue, and so we shouldn’t (and can’t) prescribe fixing only one aspect when analyzing an attack.

A1 – Broken Object Level Authorization

As more API frameworks come online with stronger server-side validation, we see this less often. However, when combined with other techniques, this vulnerability can be quite painful.

A2 – Broken User Authentication

Time and time again, organizations create authentication routines that have serious flaws like passing BASE64 encoded strings in the clear or password resets that allow for any user’s account to be reset and sent to the attacker. From the perspective of automated attacks against APIs, Credential Stuffing is on the rise and will probably be the largest attack variant we will see for the near term.

A3 – Excessive Data Exposure

Simply sniffing mobile app traffic shows us how different API endpoints are used. Taking an Android App APK apart exposes the API endpoints, but often the API itself will point to another API endpoint allowing an attacker to see what is available so they can begin testing. Utilizing a proxy and pulling the APK apart gives us (and an attacker) data about the application that not that different from running dynamic and static analysis on a web application. Obviously, when we are on the API side watching the traffic, we can easily see what is being used, but data exposure can happen on the client end. We often see attacks that are on older “thought to be deprecated” APIs that are inferred from the requests that are made. /api/v4/login gives an attacker a map to try /api/v1/login and api/v2/login etc…

A4 – Lack of Resources & Rate Limiting

Denial of Service is often not viewed as a vulnerability because it can be offloaded to a service provider for mitigation. However, what happens when the API accepts a file that is larger than the available disk? What if the compressed data expands beyond memory or disk? These types of resource attacks enable infrastructure to be taken offline. Rate limits can mean the difference between a successful credential stuffing attack and only being able to take over one account.

A5 – Broken Function Level Authorization

As organizations lose track of the various API versions in their environment, this one becomes more and more prolific. Often a new version of an API includes controls for administrative functions or access to methods like DELETE. The older API versions often have things like /api/v2/admin exposed, allowing an attacker to enumerate admin functions.

A6 – Mass Assignment

Some retailers have rewards programs. Wouldn’t it be nice if you could run an API call that does a get for /api/v1/user/<profileID> and returns { name:bob points:1003} but then a put to the same endpoint with { name:bob points:100003} in the data field? If this works, your API is vulnerable to mass assignment and is something that can become a huge problem.

A7 – Security Misconfiguration

We have all been there, forgot to set a flag or shut down a service. Often, we look at APIs and start seeing attack traffic against connect methods that shouldn’t be on, for instance, DELETE on an endpoint where GET should be the only method. These misconfigurations are often something that can be fixed quickly but left introduce significant risk.

A8 – Injection

It is curious this is number 8 on the API list but has hovered in the top two on OWASP’s Application Security Top 10. Attacks against APIs often don’t use this technique because APIs weren’t meant for humans to be able to decipher and error messages aren’t that verbose regarding deep system faults. In any case, we rarely see injected traffic attempting to do something except for the occasional command injection.

A9 – Improper Asset Management

Hygiene in knowing what API endpoints exist has and deprecating and turning them off when appropriate. We often see APIs running that only support an old app version in order to not force upgrades on user devices. It is a repeat of arguments we’ve all had with organizations that run bad cryptographic routines in order to allow older browsers to connect to web applications. Almost every compliance regulation enforces the point that asset inventory is required. Most organizations are missing this. Our suggestion is that this is moved up the list.

A10 – Insufficient Logging and Monitoring

We have had customers notice two-year-old accounts become active with a password reset and email address change, then go on to immediately login and attempt a purchase. Are they good or bad? If your logging and monitoring solutions aren’t online or able to detect this activity, you can easily see how it may lead to an unnoticed security incident. Having a good solution for this can mean the difference between a compromise and just writing a small rule to block the traffic.

Applying Real-World Context to Successful API Attacks

Tackling items in the OWASP Top 10 list one by one might end in a game of whack-a-mole as attackers morph their strategies to avoid your mitigations. To effectively tackle API security, organizations need an approach that will address several vulnerabilities at once.

If we were to take a fresh look at API security, a look that disregarded the idea of a “Top 10” and focused on real-world attacks, we might see something very different. Take a look at some examples of recent API incidents below. Combining techniques is how the attackers are winning.

Parameter Vulnerabilities

These are often discovered through a combination of techniques such as recon against the API, reading mobile application endpoints from applications, or watching an API interact using an intercept proxy. Vulnerabilities are exposed when parameters work across various user accounts, appear in error messages, or are learned via some other mechanism but work without validating (server-side) that the parameter is something the user is authorized to do. Server-side validation, safe error messages, and ensuring unused or deprecated endpoints are removed can go a long way towards preventing parameter vulnerabilities.

Business Logic Exploitation

This can come from error messages being a tad too verbose, from response payloads differing based on inputs and requests to the service, or it can be a simple logic flaw that gets exploited. Excessive data exposure and without rate limiting means that an attacker can test over and over again without overwhelming the system while attacking as efficiently as possible.

Lack of Visibility and Oversight

This can be as simple as “we don’t know what APIs we have” or more complex workflows “that user hasn’t logged-in in two months and never from Nigeria”. Being able to watch transactions, understand the intent of a transaction, and being able to react when a breach is ongoing, is critical in today’s world. Most organizations take small steps like logging data, but most don’t have the logs alert them to problems, and often attackers know this. If someone gets access to the API and breaches data on a system that isn’t instrumented to record the attack, it will be difficult to see when and how it happened.

Automated Scanning and Credential Stuffing

These are often in the news because many organizations put credential ownership in the hands of their users and have a combination of other flaws, like no rate limits, which make finding accounts and authenticating them easy.

Take a Holistic Approach to API Security

The API Top 10 is a good start at understanding the security implications of APIs and that they are rapidly becoming the foundation of most organizations’ business logic. Tackling vulnerabilities one-at-a-time might not get you out of the security debt you have built. However, taking a more holistic approach will lead to greater success.