Team Traceable
API Abuse: Types, Causes, and How to Defend Against Them
There are a few real-life analogies we can use to describe APIs. One is that they’re like doors that provide access to an underlying system. It’s an apt security analogy. You want doors to open smoothly and welcome you and your guests while keeping bad guys out at the same time.
People in the API economy often talk about developer experience (DX). They want APIs that are welcoming to developers. A fast onboarding experience, an excellent developer portal, a great API design, and well-written API documentation are staples of successful API providers.
However, there’s always the risk that making an API accessible for legitimate consumers also means handing the key to your front door to potential abusers. APIs are an attacker’s favorite. Why search for a backdoor when the front door is right there?
API abuse is often a way to describe the multitude of ways that an attacker gains access to an organization, and typically results in sensitive data exfiltration. It can come in the form of gaining unsanctioned access, account takeover, even using malicious bots to attack APIs.
Let’s talk about API abuse and how to prevent it.
Types of API Abuse
We can generally distinguish two types of API abuse. One exploits vulnerabilities of the API that exist due to neglected API security. The other relies on the unintended usage of otherwise legitimate API access.
Let’s quickly talk about the latter before focusing on the former for the remainder of the article.
Data Scraping Through Legitimate API Requests
Most abuses of the unintended-but-legitimate kind involve data scraping. The API provides access to data that’s useful and necessary in some scenarios, but malicious actors could use it for nefarious purposes. A prominent example is the Cambridge Analytica scandal. The company gathered personal data about potential voters from Facebook and sold it to political campaigns.
However, they never hacked Facebook. They created a quiz app using Facebook’s API. Then they asked users for access permissions, which the users granted willingly. They got all the data through approved API requests.
There’s no simple Band-Aid available for problems like this. Thinking like a potential adversary in the API design process is crucial. Be careful with the scope of your API and the data you expose. Include only as much data in the API as you need. You can always extend it later. Ask yourself what’s the worst thing someone could do in your system that would be possible with legit API calls. Think of your API’s many use cases beyond your original intentions.
Exploiting API Vulnerabilities
Problems based on exploiting vulnerabilities generally have a more straightforward path to a solution that includes a tool kit for fighting abuse. Let’s look at some common issues in this area and how to solve them.
DoS Attacks
Denial-of-service attacks are typical attacks that hit websites and APIs alike. An adversary generates more traffic than the target can handle, often from a distributed number of sources. While this isn’t an API-specific attack, standard solutions that differentiate human and bot traffic aren’t helpful.
As API consumers can be automated systems that behave unlike humans, the goal must be to differentiate the good bots from the bad instead of blocking all bots. Scanning for bot-like traffic only works if you expect API calls based on user requests alone.
Some other tools are available, such as rate limiting to allow a certain number of API requests in a given timeframe. Rate limiting can apply to the source IP addresses and API keys. Don’t allow more requests than you’d expect a legitimate API consumer to make, and block out the excess through an API gateway or proxy servers.
Attackers may exploit the fact that a small API call could result in a significantly sized response or extensive server-side computation needs. You can limit the amount of data in a single call through pagination and smaller data schemas and restrict the complexity of queries available to clients. Also, you can increase your API’s performance through performance testing and continuous tuning so that it won’t quickly bog down under load. Potential adversaries shouldn’t have it too easy.
Injection Attacks
Next are injection attacks, where abusers send requests that trigger undesired behavior through a bug in the implementation. There are different subtypes of injection attacks, but SQL injections are the most common. If the API’s back-end code doesn’t validate and sanitize inputs from the client before passing them to a database, consumers might be able to trigger arbitrary SQL queries.
Those queries could bypass access controls or even delete data. The cure for injection attacks is a robust API implementation.
Modern development frameworks have abstraction layers between your code and the database. If you have an OpenAPI definition for your API, you can use an API gateway or a library in your back-end code to validate inputs against the specification. This way, you can prevent many invalid requests.
Besides SQL injections, there are various injection attacks that are specific to certain frameworks or programming languages.
Authentication and Access Control Issues
Many security issues are related to authentication and authorization. A reminder: authentication is about establishing the requester’s identity, and authorization is about verifying their access rights. There are exploits for both.
APIs typically use API keys or HTTP Basic authentication. API credentials can easily leak when consumers use them on the client, such as in a web or mobile application. If API providers expect such usage, they should hand out two sets of credentials, one for low-value public data and one for private high-value data. Consumers should include the latter only in server-side implementations. It is widespread to have both an application or client identity and authenticate the application’s end user for additional security. You should use a standard protocol like OAuth for such authentication scenarios and ensure its proper implementation. Revoke credentials that were misused and hand out time-limited access tokens.
For authorization, there are different models, such as role-based access control (RBAC) and object-level permissions. Depending on each application, they can be more or less sophisticated and finely grained. It’s essential to prevent users from accessing objects without proper authorization. This isn’t a problem specific to APIs, but APIs give a good insight into the application data structure. Upon learning about it, attackers might guess parameters and identifiers and reveal data they are not authorized to see. Because trial and error can be outside expected API consumer behavior, you might easily miss this.
Here’s an example: Consumers try another random resource identifier after accessing a resource in the API. The back end must verify that the consumer is allowed to access the other object. If they aren’t supposed to access it but there’s no check, the access control on the object is broken. Hence, problems with permissions checks are called broken object-level authorization, or BOLA.
The QA Process to Prevent API Abuse
A quality assurance process for an API should include API testing and API monitoring. Developers run tests during development and deployment to verify that the API works. After deployment, API monitoring ensures that the API behaves as expected and doesn’t break in production.
API Security Testing
Testing can cover various aspects of an API. Typically, you start with functional testing of single units, such as API calls. Then you test the functionality of more complex API usage scenarios. Finally, you can run performance tests to ensure the API remains fast and responsive under load. Another aspect of API testing is security testing, which is crucial to prevent the abuse of your API.
Most tests are positive. You define an expected behavior and verify that the product under test—e.g., your API—exposes that behavior. For API security testing, however, you need negative tests. The approach is also known as fuzz testing. In a negative test, you provide invalid or even malicious input. Then you assert that the API responds with a proper error message instead of accepting and handling the request in unexpected ways.
A minimal negative test could be an attempt to access an existing resource in the API without proper authentication or authorization and verifying that the API doesn’t return any data. We have a whole article about API security testing on our blog, where you can read more about defining and implementing these test cases.
API security testing helps prevent common security problems. We’ve outlined a few of those problems in this article and in the previous one on security testing. The API Security TOP 10 from OWASP is another good resource if you want to learn about these issues and how to prevent them. However, there’s a high likelihood that you’ll oversee problems during testing. Hence, you need to observe your system through API monitoring continuously.
API Monitoring
The primary purpose of API monitoring is to guarantee the uptime and performance of the API that you’ve promised to your clients. It can help you find problems that only appear over time or under a particular load. Some API security issues fall under that as well. For example, if an API returns low-level system errors after crumbling under stress, those errors could leak security-related information.
Continuous API monitoring can also find problems with formally proper but unexpected API usage, such as unusually high loads and data scraping patterns like trying out many resource identifiers. It can also observe the usage of API endpoints that you didn’t even test because you didn’t know they existed. Those endpoints could be internal API routes used by the public or temporary routes added for testing that somehow ended up in production.
Logging API usage is the first step toward a complete monitoring system. You can find those unexpected requests and identify patterns by evaluating your logs.
In summary, there’s no silver bullet to prevent API Abuse. Instead, you must carefully design your API for a minimum exposure surface, diligently follow API security testing best practices, and add continuous API monitoring.
Conclusion
In summary, there’s no silver bullet to prevent API abuse. Instead, you must carefully design your API for a minimum exposure surface, diligently follow best API security testing practices, and add continuous API monitoring.
About Traceable
Traceable is the industry’s leading API security platform that identifies APIs, evaluates API risk posture, stops API attacks, and provides deep analytics for threat hunting and forensic research. With visual depictions of API paths at the core of its technology, its platform applies the power of distributed tracing and machine learning models for API security across the entire software development lifecycle. Book a demo today.
