What are API Attacks, Why They’re Different, and How to Stop Them

API attacks have been all over the news lately. Just a few weeks ago, a major telecommunications company in Australia experienced an API security incident, exposing around 10 million customer records. In March, a Hubspot API breach exposed the sensitive data of 1.6 million users. And who can forget the 2021 barrage of API security breaches that included Peloton, John Deere, and Experian? Gartner’s prediction that “by 2022, API abuses will move from an infrequent to the most-frequent attack vector, resulting in data breaches for enterprise web applications” has certainly come true.

Why are we seeing such a constant stream of API-based attacks? Quite simply, APIs are lucrative for attackers. They’re like airport ramp agents, directing bad actors with their glowing red sticks, right to their most precious data.  

Because APIs also drive today’s digital economy, this presents a quandary. You can’t just decide to eliminate them or limit access without slowing down your business innovation. Your only real choice is to secure your APIs against today’s — and tomorrow’s — attacks to ensure your business can continue to grow and deliver the services that your customers expect.

Many organizations erroneously believe “security through obscurity” suffices to protect them — they’re unknown enough, their data isn’t intriguing enough, their APIs are different enough, they’re safe enough. Sadly, this approach has never worked and will definitely not work in the digitally-connected, data-everywhere, API-first world.

What is an API attack?

An API attack is simply a hostile usage — or attempted hostile usage — of an API. Attackers use an API endpoint to access and exploit data. Sometimes, these attacks can be perpetrated due to fundamentally poor code. But more often, they target business logic vulnerabilities, trying to make APIs behave in ways never intended by their developers.  

Making matters even more challenging, every API vulnerability essentially represents a zero-day vulnerability. Because each company’s APIs are unique to them, each API’s security gaps differ from another. Consequently, in order to figure out how to effectively exploit APIs, attackers must poke and prod — over and over again — to uncover any business logic mistakes and learn an API’s vulnerabilities. Spotting these “low and slow” attacks, which can be conducted over days, weeks, and even months requires deep behavioral analysis over time.

How are today’s API attacks different?

As the number of APIs has increased, the threats themselves have changed. This new attack paradigm has arisen because APIs have been built upon business logic and underlying application logic. As mentioned, the most significant API security risks stem from business logic flaws.

Transaction-based attacks – such as a typical SQL injection — comprised the majority of past security attacks. Traditional proxy-based security solutions, like a WAF, work well at stopping these types of attacks; WAFs look for known patterns and act as a firewall, blocking the known bad. However, server- or VM-based API security approaches simply don’t have a broad enough data set over time to identify today’s sophisticated API attacks.

In application logic attacks, hackers use reconnaissance over time — to uncover holes in coded business logic. They seek areas for potential exploitation, such as gaining unauthorized access to data or functionality within the API, or weaknesses in the API to launch pin-point, low-traffic, application denial-of-service (DoS) attacks.  

Because of this, attacks rarely stem from a single API call. Attackers make multiple API calls as part of their reconnaissance efforts. While traditional security solutions can defend against known vulnerabilities, they cannot discover these logic-based API vulnerabilities. They lack the needed business function and logic.

To protect APIs, organizations must be able to spot logic-based vulnerabilities in APIs. This requires business function and business logic context. Security teams must see the API’s endpoints in action and understand the functional purpose of each of the endpoints. They also need to understand the behavioral characteristics of each parameter and element in use by those endpoints. A single API endpoint alone can have thousands of possible permutations of business and underlying application logic that need to be vetted and exercised to understand if the endpoint is capable of performing any negative behaviors.

What types of API attacks are most common?

The Open Web Application Security Project (OWASP), the organization that brought us the Top 10 vulnerabilities, has done the heavy lifting to help the market understand today’s most common API security attacks. In late 2019, OWASP released its first-ever API Security Top 10 list of vulnerabilities, including the following top ten API attack types:

• API1:2019 Broken Object Level Authorization: Broken object level authorization is the most common API threat, represented in about 40% of all API attacks.
• API2:2019 Broken User Authentication: Broken user authentication enables attackers to use stolen authentication tokens, credential stuffing, and brute-force attacks to gain unauthorized access to applications.
• API3:2019 Excessive Data Exposure: When generic APIs provide more data than is needed, an attacker can exploit an app by using redundant data to further extract sensitive data.
• API4:2019 Lack of Resources & Rate Limiting: APIs that improperly implement rate limiting or neglect to implement it at all are highly susceptible to brute-force attacks.
• API5:2019 Broken Function Level Authorization: When authorization is not properly implemented, unauthorized users can execute API functions such as adding, updating, or deleting a customer record or a user role.
• API6:2019 Mass Assignment: APIs that directly consume input requests and assign/write them to the business logic data stores are vulnerable to mass assignment, allowing attackers to change critical data properties and exploit privilege escalation.
• API7:2019 Security Misconfiguration: Security misconfiguration is a catch-all for a wide range of security misconfigurations that often negatively impact API security as a whole and introduce vulnerabilities inadvertently.
• API8:2019 Injection: This attack is the one hold-over from the original OWASP Top 10 list – the other 90% are new and focused just on APIs. Attackers exploit injection vulnerabilities by sending malicious data to an API that is in turn processed by an interpreter or parsed by the application server and passed to some integrated service.
• API9:2019 Improper Assets Management: An outdated or incomplete inventory results in unknown gaps in the API attack surface and makes it difficult to identify older versions of APIs that should be decommissioned.
• API10:2019 Insufficient Logging & Monitoring: Insufficient logging and monitoring, combined with missing or ineffective integration with incident response, allows attackers to perform reconnaissance, exploit or abuse APIs, compromise systems, maintain persistence, advance attacks, and move laterally across environments without being detected.

Unfortunately, the Salt Security Q3 2022 State of API Security report indicated that only 55% of respondents rely on the list of OWASP top 10 API attacks. Given that 62% of attempted attacks against organizations leverage at least one of those methods, this represents a missed opportunity.

Are my existing tools enough to protect our API attack surface?

As we’ve discussed, APIs require a new approach to security with dedicated solutions leveraging architecture that goes beyond traditional tools that are limited to looking at individual transactions in isolation.

In a recent research note, Gartner acknowledged the need for dedicated solutions by adding API Security as a distinct tier in their updated Security Reference Architecture. This new tier sits between traditional tools such as WAFs, WAAPs, API gateways, and CDNs that protect the edge and tools that protect the data and control plane. With this new architecture, Gartner affirms that these traditional tools leave gaps in API protection.

To protect APIs, organizations need a platform specifically created to address today’s unique API security considerations that includes:

• Visibility: API sprawl continues unabated, making it nearly impossible to stay up to date on new and changed APIs. Organizations also need insights into where their APIs expose sensitive data.
• Attack prevention: Every API is unique, so attacks are unique, and organizations need the ability to detect the low-and-slow behavior of bad actors probing APIs in search of business logic flaws.
• Proactive security: Remediation insights, gleaned from pre-production testing as well as runtime,  help developers harden their APIs. Organizations must not overly rely on shift-left tactics. However pre-production testing won’t uncover business logic flaws, so developers cannot be expected to build secure APIs every time.

To prevent API attacks, you must first know what APIs you have

An accurate view of the attack surface is essential to inform your security strategy but this can be especially challenging with constantly-changing APIs. In fact, a recent Salt Security survey found that 11% of respondents updated their APIs daily and 31% updated them weekly.

You need to discover all of the APIs in your environment, including unknown shadow APIs, as in the example above, and zombie APIs that should be deprecated. Discovery must be automatic and continuous to keep up with the constant release of new and updated APIs and must cover all customer-facing, partner-facing (provided and consumed), and internal APIs.

Knowing an API exists is not enough. Understanding each API at a granular level is critical to understanding the intended functionality, assessing risk, and determining if the API exposes sensitive data such as personally identifiable information (PII). Automatic and continuous discovery helps ensure that the view of the attack surface and sensitive data exposure remains up to date at all times.

Cloud-scale big data and mature AI models help prevent API attacks

Attackers targeting APIs use subtle methods to uncover and exploit vulnerabilities. Consider fraudsters attempting to redirect ACH transfers to alternate, unauthorized account numbers. The fraudsters could exploit a commonly found API vulnerability and manipulate routing numbers by changing only a few API parameters.

To spot this, you need a solution that combines big data, AI, and ML to capture all API traffic, create a baseline of normal activity, and look for deviations. In the case above, this type of a solution would identify the subtle routing number manipulation and flag the activity.

Only a cloud-scale big data architecture with artificial intelligence (AI) and machine learning (ML) can capture and continuously analyze large volumes of API traffic. Continuous analysis of API traffic provides the only path to understanding normal behavior for each unique API and gaining the context required to identify subtle deviations and pinpoint attackers.

API protection also requires analysis of API traffic over time. By their nature, APIs expose application logic. Hackers do lots of experimentation to try to identify the gaps in business logic that they can exploit. The reconnaissance needed to propagate attacks like these takes a lot of time. A single API attack can take hours, days, or even weeks to unfold.

After you’ve stopped the “bleeding”, it’s time to eliminate future gaps

DevOps teams play an essential role in security, but any software will inevitably release containing gaps despite teams employing development best practices and leveraging scanning tools. APIs are no different. Agile development practices and tight release cycles mean that stretched-thin development teams may miss security to meet tight schedules.

Runtime protection is critical to prevent exploitation of any vulnerability that makes it to production. But relying solely on runtime protection leaves you in a situation of playing a virtual game of whack-a-mole. Gaps must continually be identified and eliminated by dev teams to improve API security.

Today’s leading API security solutions can block fraudsters and learn from their activity as they probe and manipulate the API. These learnings then provide insights into the vulnerabilities unique to that API and help development teams prioritize and eliminate gaps quickly.

It’s a constant race! API security solutions must analyze APIs to identify gaps before an attacker finds them and enable developers to proactively eliminate potential vulnerabilities while simultaneously sharpening their API security best practices.

For more information

Contact us or schedule a personalized demo to learn more about how the Salt Security API Protection Platform can help your organization build a complete and accurate API inventory, uncover API attacks in runtime, and gain insights to remediate vulnerabilities and harden your APIs.