Akamai Diversity

Akamai Security Intelligence
& Threat Research

The Dark Side of APIs: Denial of Service Attacks

Ryan Barnett, Principal Security Researcher, Akamai

Elad Shuster, Senior Security Researcher, Akamai



In this blog post, we will discuss different Denial of Service (DoS) attacks that may negatively impact  your API services, as well as mitigations offered by Kona Site Defender (KSD).

Infrastructure Layer vs. Application Layer

DoS attacks can take many shapes and target an entire network and platform stack. The vast majority of DoS attacks target lower level networking protocols and focus on volumetric flooding of the upstream network pipe.  Memcached is one such example.  Figure 1, from the Q4 2017 State of the Internet report, illustrates that infrastructure attacks far outweigh application layer attacks from a frequency of attack perspective:

Figure 1: DDoS Attack Vector Frequency

Organizations that are using a Content Delivery Network (CDN) for DoS protection, oftentimes will not see or feel the full effects of these constant DoS attacks as the CDN network absorbs the attacks.  However, for application layer attacks, traffic could potentially be forwarded from the CDN onto the customers application. We will be focusing our DoS discussions on these application layer attack vectors.

Volumetric Flooding

DoS attackers still attempt to overwhelm web applications and APIs with a flood of HTTP/HTTPS requests.  In order to obtain a high enough level of traffic, attackers typically need to leverage a large number of attacking hosts to achieve the desired effect.  One way to do this is by purchasing access to a "booter service" - which is a marketing term for "DDoS for Hire". Below is an architecture diagram, provided by Brian Krebs, that shows how booter services typically work.

Figure 2: Example Booter Service Architecture

Volumetric Flooding - Mitigations

When Kona Site Defender (KSD) customers receive volumetric flooding of HTTP(S) requests destined for their API endpoints, many protections should trigger.  

Figure 3: Security Monitor's Denial of Service Dashboard


There are 4 different protections that are shown in the figure above:

  1. Network Controls - this allows for blacklisting of IP addresses and CIDR ranges

  2. Rate Controls - which is specific to volumetric flooding attacks as the KSD customer can specify different criteria for thresholds.

  3. Slow Posts - Kona Site Defender (KSD) has protections against attacks that try to consume application resources by opening an HTTP connection and then sending data very slowly.

  4. DoS Risk Group - many web DoS tools and scripts have tell-tale fingerprints and be easily identified and blocked using WAF protections.

Using API Keys for Rate Controls

During the API onboarding process in KSD, it is possible to define an "API Key" if present in requests:

Figure 4: Defining API Key Location

The advantage to defining an API key is that it can be used to when building Rate Controls. This provides more granularity for APIs instead of only relying upon client IP addresses.  Here is an example of using a predefined API key in a Rate Control definition:


Figure 5: Using an API Key as Client Identifier for Rate Controls


With this in place, any Rate Control events shown in the Dashboard should  show the following:

Figure 6: Rate Control Event Using API Key

Processing Consumption Attacks

Another DoS attack vector that can be used against APIs, is when attackers  target CPU/RAM allocations on the API server itself, rather than targeting network bandwidth.  For each web request that the API receives, it has to allocate CPU/RAM for processing and there are limits on concurrent availability.  An attack known as Hash Collisions,  can impact APIs that accept JSON formatted request body data from clients.  When these APIs are processing JSON body content, they must create a hash table of all JSON nodes.  During this process, node name content is compared in the hash table to prevent collisions.


Figure 7: Hash Table Checking for Collisions


If an attacker sends a malicious JSON request body, with an extremely large number of nodes, it can cause an increase of hash collision checking when building the hash table.


Figure 8: Malicious JSON Request

The impact can be seen on the local API server if you monitor the processing time as seen in Figure 9:


Figure 9: JSON Hash Collision Processing Time

Processing Consumption Attacks - Mitigations

KSD's API Management interface allows the customer to define Request Body Constraints, which includes  setting a limit on the number of allowed JSON keys:


Figure 10: Setting Max JSON Keys


In this case, by setting this limit, any JSON request that has more than 50 keys will be blocked.

Scraping or Denial of Service? - The RANGE Attack

APIs allow for quick access to data, however this capability can also be abused for bulk extraction of data.  Web scraping campaigns can cause many different issues for web site owners, as APIs can be targeted in these attacks leading to DoS conditions. The Netflix security team gave a great presentation at last year's DefCon, where they discussed many denial of service scenarios they faced with their APIs and microservices.  One of the scenarios presented was the RANGE attack. In this scenario, there is an API that allows the user to submit a JSON request that includes a range of data to be extracted.  Figure 11 shows an example with the "from" and "to" JSON nodes.


Figure 11: JSON with Range Elements

In this context, the amount of data returned is variable.  Web scraping campaigns can abuse this feature to initiate bulk extractions of data.  Malicious clients who want to cause a DoS condition could specify a very large range as shown in Figure 12:

Figure 12: JSON with Malicious Range

This request could cause a DoS condition on a separate backend API tier.

RANGE Attack - Mitigation

KSD's API Management interface allows the customer to define JSON/XML node attributes, including an allowed range of data as shown in Figure 13:


Figure 13: Defining Acceptable Range for JSON Node


With this setting defined, if the range of data specified in the "to" JSON node is more than 20 it would be blocked.


DoS attacks can take many different forms with non-HTTP vectors being the most common.  While the volumes of application layer HTTP(S) DoS attack vectors is smaller in comparison, they can still have devastating consequences to websites that are not properly prepared.