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.
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.
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.
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:
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.
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:
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.
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.
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.
Contact us 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.
Dr. Anton Chuvakin, security advisor at Office of the CISO, Google Cloud, joined our recent API Security Summit. Dr. Chuvakin’s session – co-hosted by Salt Security's Michelle McLean – provided an in-depth discussion on why API security has become a “now” problem.
The monetary growth opportunities promised by APIs are immense, but to harness them, CISOs must ensure the protection of their APIs.
With the industry moving to microservices and API-driven applications, new security threats and attack vectors have emerged. The PCI Security Standards Council has worked to address these threats in its newest PCI DSS 4.0 standard.