Beyond Vulnerabilities: Why API Abuse is the Next Big Security Battleground

As APIs grow in strategic importance, organizations are gradually increasing their level of API security maturity and sophistication.

These initiatives generally start with three primary activities:

1. Implementing API discovery to create a complete and accurate inventory of all sanctioned and unsanctioned APIs.
2. Eliminating unsanctioned APIs.
3. Identifying and remediating software and implementation vulnerabilities that leave sanctioned APIs exposed to attacks.

These are all essential practices, and there are some excellent resources like the OWASP Top 10 that provide a high-level roadmap for finding and eliminating API vulnerabilities.

But here’s the problem. Discovering APIs and addressing API vulnerabilities is just the tip of the iceberg for understanding and mitigating API risks.

Why?

Because even if you do a perfect job at cataloging your APIs and eliminating vulnerabilities, they may still be highly susceptible to abuse. And the business impact of API abuse can be just as devastating as vulnerability exploits.

API abuse is a very different kind of problem

Early efforts at formal API security viewed the problem through the lens of:

• Vulnerabilities in how APIs were coded or configured
• Attacks that exploit those vulnerabilities

API abuse is different in that attackers are not exploiting any type of technical vulnerability. Instead, they are using APIs in ways not intended by the organization that created them.

It sounds simple and benign, but the effects of API abuse can be pretty devastating. After all, many organizations expose their core business logic and data through APIs. The only thing a threat actor needs to steal this intellectual property is the right API with the right credentials.

The business impact of API abuse can be devastating

One extreme example that illustrates the cascading impacts of API abuse is the Cambridge Analytica (CA) scandal that thrust Facebook into the spotlight in 2018. In this case, CA abused Facebook’s open APIs to gather extensive data about at least 87 million users. This was accomplished using a Facebook quiz that exploited a very permissive setting that allowed third-party apps to connect information and both users AND their social connections.

Demographic and psychographic profiles derived from this data were then sold and used to influence public opinion about issues like the 2016 U.S. presidential election and the UK “Brexit” referendum.

None of this involved exploiting an infrastructure vulnerability in Facebook’s API infrastructure. Instead, CA simply used Facebook’s public API in ways not intended or anticipated when it was created. In short, Facebook exposed a core business API that was ultimately abused.

Every organization that exposes APIs does the same thing on a smaller scale every day. It should be assumed that every API has potential abuse case scenarios associated with it.

For example, consider the online banking, budgeting, and financial planning applications and services that many of us now use every day. APIs are the key to making these types of conveniences work. But a threat actor with credentials in hand could easily take advantage of the inherent business logic and data accessible through these APIs to turn this intellectual property against the financial institution’s business interests and the account holder’s personal interests.

Further complicating matters is the fact that API abuse is very difficult to detect. Because threat actors are using valid credentials and interacting with APIs in ways that look similar to legitimate usage, many first-generation API security products aren’t able to detect them.

How to defend against the growing threat of API abuse

First off, don’t take your eyes off API vulnerabilities. It’s just as important as ever to build an API security foundation that includes discovery, vulnerability assessment, and remediation.

But extending your API security posture to address the complete array of API threats, including API abuse, requires three important shifts.

1. Expand your thinking about what constitutes an API attack.

   Outside of API security, we look at threats in two main ways:

   • Systematic approaches for discovering, documenting addressing vulnerabilities (e.g., MITRE CVE)
   • A living knowledge base of known attack techniques (e.g., MITRE ATT&CK)

   We have a start at the first with OWASP API Top 10. But, unfortunately, we’re missing the second when it comes to understanding API abuse.

   Until industry frameworks for this emerge, it’s important for your team to think more broadly about the nature of API attacks.

2. Analyze significantly more data about APIs and activity.

   Most first-generation API security approaches only monitor individual API calls or, at best, short-term sessions. The problem with this is that in addition to looking like legitimate activity, API abuse may unfold over minutes, hours, or days.

   Adopting a SaaS-based approach is really the only way to capture and analyze large enough data sets to truly understand API usage in context and spot “low and slow” API abuse and anomalies from normal baselined behavior.

3. Harness API to spot instances of abuse.

   The speed and volume of API activity is too great for humans to monitor and understand actively. At the same time, many traditional API security techniques cannot understand the business impact of what they are observing.

   This is an excellent application of machine learning and AI techniques. Assuming that you follow the advice above and shift to SaaS, in addition to having more data to analyze, you’ll have access to the computing power to perform big data analytics.

   We will never be able to predict the future and completely anticipate the next novel way that threat actor will abuse an API. But we can use AI to baseline normal behavior, understand the business entities involved, and spot anomalies that indicate possible abuse.