A foundational component that enables innovation and rapid exchange of data between people and applications or between machines is the Application Programming Interface (API). From banks, e-commerce, and transportation to IoT-connected devices, autonomous vehicles, and smart cities, APIs are a critical part of modern mobile, SaaS, and web applications. APIs have also become a lucrative target for attackers because they expose application logic and sensitive data. Hence, API security should be a top consideration for everyone to secure innovation and digital transformation.

How Is API Security Different?

The most popular API architectures are REST and SOAP. Both are considered web APIs, and while they share many similarities with web applications, they also present fundamental differences. 

In traditional web applications, data processing is done on the server side, and the resulting web page is then sent to client browsers simply to be rendered. In this architecture, the entry points into the business are relatively few and easy to protect by setting up a web application firewall (WAF) in front of the application server.

Modern API-based applications are different. The UI uses APIs to send and receive the data from the back-end servers to provide the functions of the application. The server is used more as a proxy for data, while the rendering component is the client. 

The image below provides an illustration of this fundamental difference.

In an API-based apps environment, the entry point into the business is the plethora of APIs that call to the back-end server. With so many entry points often geographically distributed, installing a WAF in front of a server is no longer enough to ensure all entry points are protected. In addition, a traditional WAF-based solution has no means to distinguish compromised API calls from legitimate API traffic.

This limited perspective is increasingly important because in an API environment, where clients consume raw data, APIs expose the underlying implementation of the app, and more parameters are sent in each HTTP request (object IDs, filters).

Finally, known, pre-defined vulnerabilities are not the biggest source of concern in API-based apps. Instead, to provide ample protection, security needs to focus on strategies and solutions that can identify, understand, and mitigate the unique vulnerabilities and security risks of APIs.

OWASP API Security Top 10 Project

These new API-based challenges prompted OWASP to create a separate project dedicated to API security. The OWASP API Security Top 10 project focuses specifically on the top 10 vulnerabilities in API security and recognizes:

• The crucial role that APIs play in application architecture and therefore in application security
• The emergence of API-specific security issues that need to be mitigated

Here’s the API Security Top 10 with a quick explanation.

API1:2019 Broken Object Level Authorization

Attackers substitute the ID of their own resource in the API call with an ID of a resource belonging to another user. The lack of proper authorization checks allows attackers to access the specified resource. This attack is also known as IDOR (Insecure Direct Object Reference) and is the most common form of API attack.

API2:2019 Broken User Authentication

Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens and compromising a system’s ability to identify the client/user compromises API security overall.

API3:2019 Excessive Data Exposure

The API may expose a lot more data than what the client legitimately needs, relying on the client interface to do the filtering. If attackers go directly to the API, they gain access to all data.

API4:2019 Lack of Resources & Rate Limiting

The API is not protected against an excessive number of calls or payload sizes. Bad actors can use this attack for Denial of Service (DoS), impacting the application’s performance or availability, and brute-force attacks.

API5:2019 Broken Function Level Authorization

Complex access control policies and an unclear separation between administrative and regular functions may lead to authorization flaws. By exploiting these issues, attackers can gain access to other users’ resources and/or administrative functions.

API6:2019 Mass Assignment

In this attack, the API takes data that a client provides and stores it without proper filtering for whitelisted properties. Attackers can try to guess object properties or provide additional object properties in their requests, read the documentation, or check out API endpoints for clues on where to find the gaps to modify properties they are not supposed to on the data objects stored in the back end.

API7:2019 Security Misconfiguration

Poor configuration of the API servers allows attackers to exploit them. Misconfigurations may include unpatched systems, outdated or misconfigured TLS protocol, poorly hardened images, permissive Cross-Origin Resource Sharing (CORS), and error messages containing sensitive information.

API8:2019 Injection

Attackers construct API calls that include SQL, NoSQL, LDAP, or other commands that the API or the back end behind it blindly executes.

API9:2019 Improper Assets Management

Attackers find non-production versions of the API (for example, staging, testing, beta, or earlier versions) that are not as well protected as the production API and use those to launch their attacks.

API10:2019 Insufficient Logging & Monitoring

Lack of proper logging, monitoring, and alerting allows attacks and attackers go undetected.

How to Secure Your API

Addressing all these API-unique vulnerabilities might seem overwhelming. The best way to deploy your security defenses is to rely on industry best practices and develop an API Security Checklist, such as the one Salt Security has produced. In the words of Michael Isbitski of Salt Security, the checklist can help you “navigate through the top items in the area of best practices, and you may opt to emphasize sets of best practices where you already have technology investments or manpower.” As a tip, you may start by picking the best practices that you are mostly familiar with and mature your program over time by adopting additional best practices to avoid leaving gaps in your API security strategy.