API Security Project Identifies Top 10 Vulnerabilities

"Broken object level authorization" is the number one API vulnerability that attackers can exploit to gain access to an organization's data, according to a report from the independent Open Web Application Security Project (OWASP).

"Attackers can exploit API endpoints that are vulnerable to broken object level authorization by manipulating the ID of an object that is sent within the request," according to the OWASP API Security Top 10 report. "This may lead to unauthorized access to sensitive data. This issue is extremely common in API-based applications because the server component usually does not fully track the client's state, and instead, relies more on parameters like object IDs, that are sent from the client to decide which objects to access."

If hit by attackers, an organization could risk not only loss or manipulation of its data but also a full takeover of its system, the report warns.

Developers are the first line of defense against this type of API attack as protection against the vulnerability needs to be put in place at the code level. Object level authorization needs to be set up in the code to make sure only a user with the correct permission can access and take action on a requested object, OWASP says.

If developers forget to make sure API authorization and access control mechanisms are set up properly in an application, the vulnerability will leave the door open for attackers, the report says. It is important to get this right and check it during development because "access control detection is not typically amenable to automated static or dynamic testing."

To illustrate how such an API breach could happen, the report offers the following scenario: "An e-commerce platform for online stores (shops) provides a listing page with the revenue charts for their hosted shops. Inspecting the browser requests, an attacker can identify the API endpoints used as a data source for those charts and their pattern /shops/{shopName}/revenue_data.json. Using another API endpoint, the attacker can get the list of all hosted shop names. With a simple script to manipulate the names in the list, replacing {shopName} in the URL, the attacker gains access to the sales data of thousands of ecommerce stores."

OWASP offers a list of actions development teams can take to make sure this doesn't happen with their application:

  • Implement a proper authorization mechanism that relies on the user policies and hierarchy.
  • Prefer not to use an ID that has been sent from the client, but instead use an ID that is stored in the session object when accessing a database record by the record ID.
  • Use an authorization mechanism to check if the logged-in user has access to perform the requested action on the record in every function that uses an input from the client to access a record in the database.
  • Prefer to use random and unpredictable values as GUIDs for records' IDs.
  • Write tests to evaluate the authorization mechanism. Do not deploy vulnerable changes that break the tests.

Erez Yalon, Director of Security Research at Checkmarx and co-leader of OWASP's API Security Project, said that he and co-lead Inon Shkedy, penetration tester and security researcher, started the project because APIs represent a security risk that is not fully recognized. The list, which includes the nine other API vulnerabilities that make up the top 10 with mitigation recommendations, is designed as a guide to help developers recognize and prevent issues that could be exploited in their applications.

A pdf of the full report is available for download here.