What you need to know about the new OWASP API Security Top 10 list

OWASP, the Open Web Application Security Project known for its top 10 list of web application vulnerabilities, published the release candidate version of its API Security Top 10 list at the end of September 2019. It’s a good time to pay attention to API security, since some high-profile breaches have involving APIs in recent months — most notably, at Capital One.

API-enabled breaches in the news

According to a report released by Akamai earlier this year, API calls now represent 83% of all web traffic. Web-enabled applications already have 40% of their attack surface in the form of APIs instead of user interfaces, according to a recent Gartner report. By 2021, APIs will account for 90% of the attack surface. By 2022, according to Gartner, API abuses will become the most-frequent attack vector.

The problems have already begun. Recent examples of organizations in the news due to API-related breaches include McDonald’s, Facebook, Twitter, Panera Bread, T-Mobile, Instagram, Salesforce, Snapchat and the US Internal Revenue Service.

The biggest name of all is Capital One, where information on more than 100 million individuals was compromised this summer. There, a configuration issue with the web application firewall allowed access to API tokens, says Johannes Ullrich, dean of research at SANS Technology Institute and director of the institute’s Internet Storm Center.  This was compounded by insufficient access controls on the part of the AWS API. “The authentication systems used by the Amazon API weren’t restricted correctly,” he says. “If you have that problem, it’s easy to find, and easy to exploit — and that’s a dangerous combination.”

API Security Top 10 Release Candidate

API1: Broken Object Level Authorization: APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object-level authorization checks should be considered in every function that accesses a data source using input from the user.

API2: Broken Authentication: Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently.

API3: Excessive Data Exposure: Developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.

API4: Lack of Resources and Rate Limiting: Often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to denial of service, but also leaves the door open to authentication flaws such as brute force.

API5: Broken Function Level Authorization: Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws, allowing attackers gain access to other users’ resources or administrative functions.

API6: Mass Assignment: Binding client provided data to data models without proper properties filtering allows attackers to modify object properties they are not supposed to.

API7: Security Misconfiguration: Security misconfiguration is commonly a result of insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive cross-origin resource sharing (CORS), and verbose error messages containing sensitive information.

API8: Injection: Injection flaws, such as SQL, NoSQL, or command injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

API9: Improper Assets Management: APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.

API10: Insufficient Logging and Monitoring: Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data.

Source: OWASP

Companies often have problems with locking down their APIs, Ullrich says. One notable example was that of the Nissan Leaf, where attackers could find out the car’s driving history and battery level, and turn on its air conditioning if they simply knew the VIN number. “Authentication is often done wrong,” he says. Unfortunately, API authentication problems are less likely to be as in-your-face as those with user interfaces. “Just because things like authentication are a little bit more hidden than in a standard browser-based application doesn’t mean that they aren’t exploitable. In fact, they are easier to exploit, and that’s what makes it so dangerous.”

What makes API-based vulnerabilities particularly difficult is that APIs are hard to change. In a traditional web application, one designed to be used by humans, fixing vulnerability problems is as simple as updating the form. “You could change data models and pages ten times a day,” says Pieter Danhieux, instructor at SANS Institute and CEO at Secure Code Warrior.

Website changes might make it difficult for web scrapers looking for data, or bots trying to pretend that they are people, but human beings adapt easily when, say, fields are moved around on a screen or the business logic changes on a website.

APIs, however, are designed to be integrated with other applications. “If you expose an API online, people are going to use it and likely build on top of it,” says Danhieux. Once connections are in place, changing the API can break those connections. “So, if you detect a security vulnerability at a later stage, fixing the vulnerability may become a difficult business decision,” he says. “The organization must weigh up the cost and risk of doing a security fix, versus breaking customer support.”

Overlap with the original OWASP Top 10

In a lot of ways, the OWASP API Security Top 10 list looks a lot like the list for web app vulnerabilities. “There’s not a lot of difference between what’s in this list and what’s been in the OWASP Top 10 over the past years,” says Jeff Williams, CTO and cofounder at Contrast Security, former global chair of OWASP, and the author of the original OWASP Top 10. “It’s all the same stuff.”

That’s not a bad thing, Williams says. “It’s pretty good work. This is really about raising awareness.” The original OWASP list, for example, has raised a lot of awareness. “A lot of people definitely do pay attention to it,” he says. “But it has been 20 years, and we haven’t moved the bar very much. It’s a pretty damning indictment of everything we’ve done in security.”

Meanwhile, API security is different from web security in many key ways, Williams says. “There’s been a transition and the risks have changed,” he says. Meanwhile, traditional scanners don’t work very well on APIs. “Static analysis and dynamic analysis, which have been used on web applications, don’t work on APIs.”

Dynamic tools have problems because it’s hard to figure out what fields to put into the JSON or XML document to send to the API, Williams says, while static tools have problems following the data flows because they are more complex.

There are also differences in the top vulnerabilities. One is in the issue of mass assignments. “Mass assignment happens when your API takes some data, usually a JSON document or XML document, parses it, and fills out the field in an object inside the application,” says Williams. The problem is when developers add more fields to the object than the API is supposed to have coming in. “Say it’s a user object and the data coming in is their name and street address and phone number,” says Williams. “But in the object, there are also private fields like the Social Security number and password.”

Attackers can abuse that by, say, sending in new data for the password field. If it’s not filtered out, the application could overwrite the user’s password, allowing the attacker to take over the account. “It’s a rare attack,” says Williams. “It’s really cool, though.”

Another area where API security differs from traditional web app security is in authentication and authorization. “Some unique nuances come in when you talk about authentication mechanisms, because APIs deal with authentication a little differently from web apps,” says Mark Wireman, specialist leader at Deloitte Cyber, “and not only authentication, but authorization. From the clients I deal with, that’s the number one concern.”

For web apps, the access is typically by actual human beings, and part of the authentication and authorization process is to ensure that people are, in fact, people and not robots, and that they are who they say they are, but the API is specifically designed to be used by automated tools.

Does the OWASP API list go far enough?

For some security experts, the new OWASP API Security Top 10 list is too generic to be very useful. “I don’t see that they’re hitting all the problems that organizations really face,” says Wireman. OWASP could do more to provide prescriptive guidance for how to fix problems, he says.

There’s a lack of guidance about API from the main standards-setting organizations, Wireman says. For example, the OWASP list references a NIST standard — Security Strategies for Microservices-based Application Systems — but that standard was withdrawn in August. “I think NIST is struggling with how to adequately communicate to the industry, especially around APIs,” he says. “I think OWASP is in a good position to help accelerate this concern, and not just from an OWASP Top 10 type of perspective.” The list could have included the risks of third-part components and the core concept of “trust but verify,” he says.

Another security problem unique to APIs that didn’t make the OWASP API Security Top 10 list is that of not securing applications against reverse-engineering. In a report released this spring by Aite Group, cybersecurity analyst Alissa Knight was able to reverse-engineer 97% of the mobile applications of 30 major financial institutions in an average of 8.5 minutes. This allows attackers to discover host vulnerabilities, keys and other secrets.

“The API vulnerabilities were staggering,” says Chad McDonald, VP of customer experience at Arxan, a cybersecurity vendor that sponsored the report. That included hard-coded API URLs, keys, tokens and certificates, he says. “This is like a homeowner leaving their key underneath the doormat along with the passcode for the house alarm.”

How to use the OWASP API Security Top 10

As with the original OWASP Top 10 list, there are several ways that enterprises can use the API Security Top 10 list. First, as part of a defensive strategy, double-check that automated and manual penetration tests hit everything on it. “API scanning is a little challenging in the industry right now,” says Deloitte Cyber’s Wireman. “But at a minimum you can use fuzzing and other techniques to at least help with identifying some of these issues.”

Second, the list can be used to improve security training for API developers. Since APIs are hard to fix after the fact, without breaking connections to other applications, security needs to be a major focus at the start of the development process, says SANS Institute’s Danhieux. Enterprises need to maintain adequate training and awareness as early as possible, he says.

The new OWASP API list highlights the biggest threats, such as authentication, business logic flaws and excessive data exposure. “This knowledge if vital in deploying the right strategies to eliminate vulnerabilities before they do serious damage,” Danhieux says.

Finally, the API Security Top 10 list can become part of enterprises’ security planning. “CISOs should definitely be aware of the items on this list,” says Wireman, “but I think this is probably too much in the weeds for a board-level discussion. The concept, definitely, should be brought up at the board level. Where APIs fit into the organization, the importance of what they bring to the business, and why it’s important to secure the APIs.”

Related: 9 API security tools on the frontlines of cybersecurity