5 API Abuse Use Cases and How to Prevent Them

What Is a Vulnerability?

Sometimes, vulnerabilities are straightforward flaws due to bad design. For example, the Tacoma Narrows Bridge in the state of Washington was built in 1940 and collapsed later that year in a 40-mph wind due to poor construction. No lives were lost (the suspension bridge underwent reconstruction in 1950 and is still standing). 

Sometimes, though, vulnerabilities are part of the actual design. Consider door locks. A door lock is not flawed because it can be unlocked. There’s no inherent design flaw in how the pins and tumblers are precision-crafted and laid out. The issue is not that the structure is poor, but their structure and precision design provide a consistent way for would-be thieves to know how to pick them. (For more information on locksport, one good organization is TOOOL).

Proper home security relies on a homeowner's understanding that the lock is not the all-encompassing security feature needed and other protections are required. 

Why talk about bridges and locks in a tech article?

What Is API Abuse, and Who Would Do Such a Thing?

Technology security is the same way – sometimes there is bad design and poor code, and sometimes the structure of software, even when designed according to proper specs, provides the right leverage for the abuse of that technology.

API abuse is common, and not necessarily because an API is inherently poorly designed. APIs have an intentionally and predictably designed structure for positive reasons. And those same reasons are what give attackers a way to abuse APIs

OWASP defines software Abuse this way:

“Create misuse and abuse cases to misuse or exploit the weaknesses of controls in software features to attack an application. Use abuse-case models for an application to serve as fuel for identification of concrete security tests that directly or indirectly exploit the abuse scenarios.”

Abuse-case models are, in short, and in part, threat modeling. Those API “locks” can potentially be picked if the idea of someone performing a virtual locksport on it is not considered during the threat modeling phase of API design and compensatory controls are not added.

An important note here: while secure coding should be followed, developers are rightfully more concerned with proper development than rigorous security testing. Don’t put all responsibility for security on developers; include a holistic organizational program to increase security, be flexible, and test. 

There are at least three types of application and API abusers:

1. Malicious
   • The intent is to disable, defraud, and destroy. I was going to write, “this is the main one to be concerned about.” But on the topic of API abuse, all abuse needs to be considered because, in the end, the API needs to remain secure and functional regardless of the reason.
2. Intentional (non-malicious)
   • The actor’s goal is primarily to test the limits or cause trouble. The attacker may be a script kiddie having “fun,” a hacktivist (not on the malicious side), or someone taking a form
3. Unintentional (non-malicious)
   • Maybe the person is pentesting and inadvertently causes an outage, or a bug bounty hunter grabs screenshots of sensitive data, or a security researcher either didn’t realize that the testing would cause that kind of trouble or opened up a flaw.

API Abuse Cases and Prevention

Here are some common API abuse cases, with a few real-life examples.

Broken Object Level Authorization (BOLA)

Since BOLA itself accounts for about 40% of all API attacks, it’s a good way to start the list. APIs create a broad access control attack surface because they handle object identifiers. 

Some ways to prevent BOLA are:

• Implementing an authorization mechanism that is dependent on user policies, verifying that the logged-in user has permission to perform the requested action.
• Using random and unpredictable values as GUIDs for record IDs.
• Writing tests that evaluate authorization.

Distributed Denial of Service (DDoS) – Cloudflare vs. Mantis Botnet

In good news, in June 2022, Cloudflare stopped an impressive HTTPS DDoS attack. Per their article, “Within less than 30 seconds, this botnet generated more than 212 million HTTPS requests from over 1,500 networks in 121 countries.”  

Not everyone can stop that massive of an assault, but some things that companies can do to keep DDoS at bay are: 

• Traffic analytics
• Rate limiting (e.g., number of requests per client/resource, request payload size).
• Auto-scaling resources (ensure alerting is on for threshold reporting).

Security Misconfiguration

Improper configuration of security settings in an application can lead to complete compromise by way of Account Takeover (ATO). 

A couple of ways to prevent this are:

• Inventory and manage all APIs, keeping an eye out for shadow and zombie APIs.
• Data governance that extends from applications to the APIs that are involved.

Excessive Data Exposure

This threat is often considered an accidental disclosure of confidential information through open interfaces or APIs. But what about intentional disclosure?

In Venmo, transactions are public by design and by default – as their tagline says: “Fast, safe, social payments.’’ This strategy of openness led to unintended data scraping issues in 2019 as, in the not-too-distant past, someone scraped the private information of 200 million Venmo users. Additionally, US President Joe Biden’s Venmo account was found. 

The researcher who discovered the flaw thought, “If I were an attacker and I had a specific target in mind, what could I glean about that person from this data? Is it useful to me? The answer is yes.”

Data exposure, intended or not, can go so far as to create national security concerns when it is abused.

Two ways to reduce or eliminate data exposure are:

1. Perform information filtering at the API, not the client level.
2. Avoid sending sensitive information when it’s unnecessary for the function.

Injection

This malicious code (more than just SQLi) modifies data sent from one program into another program and is often used by criminal hackers to gain access to private data.

Here are some ways to prevent injection:

1. Parameterized queries
2. Context-aware security to see all API activity on a timeline.
3. Replace outdated and insecure authentication methods with quality authentication and authorization.
4. Comprehensive logging, monitoring, and alerting (the lack of which is one of OWASP’s API Top Ten).
5. Data classification to aid in data governance – know the APIs and what data travels through them.

What Else Can Be Done?

There are plenty of resources out there for API security. The most popular source for beginning API protection is probably the OWASP API Top Ten, but there are more than ten vulnerabilities – people just haven’t documented the Top 10,000 yet. Make your next test better than the previous one.

An important focus is not so much simply keeping bad actors away but maintaining the reputation that your organization is a reliable company with whom customers can safely do business.