Defending Microservices using Rate Limiting and API gateways.

In the previous article, we've learned about API response aggregation and how it reduces the rate of communication between client-side components and API gateways. In this article, we will learn how to defend API gateways from DOS-based attacks using rate limiting.

Articles in the Series

This article belongs to a series of articles that explains the importance of API gateways and how to build them using Core. If you're interested to learn more about API gateways, it might be a good idea to spend some time reading the articles listed below.


Denial of Service (aka DoS) is a popular type of cyber-attack that aims to limit the capability of a server to respond to clients by degrading the quality of service via HTTP flooding (sending of HTTP requests in a quantity that exceeds the expected traffic). It was popularized by Khan C. Smith on a DEF CON event back in 1997 and was used to perform some major attacks (see below) on large corporations and public DNS servers:

  • Project Rivolta by Mafiaboy @ 2000 - Rivolta ("Riot" in Italian) was one of the largest and most popular DDOS attack that was aimed against the big boys of eCommerce (Yahoo, CNN, Amazon and eBay) back in early 2000s.
  • Root DNS Server Attacks - is a sustained DDOS attack that was levied against all of the 13 DNS root name servers. The root nameservers are critical infrastructure components of the Internet, mapping domain names to IP addresses and other resource record (RR) data.
  • Operation Ababil - is a series of DOS attacks performed against 26+ US financial institutions that was launched by the Cyber fighters of Izz Ad-Din Al Qassam.

The availability of web applications to business clients is considered as a critical factor to the sustainability of web-based businesses. Amazon says that a second response time delay can cause it around 1.6 billion dollars in sales a year. DDOS poses a huge threat to all sizes of businesses if it remains unchecked, this is the primary reason as to why rate-limiting strategy was introduced to the software development world.

Rate Limiting

The image above shows a typical rate limiting implementation.

To defend web-based applications from DDOS attacks, several defensive techniques can be employed and one of them is rate limiting. Rate Limiting is a technique used for controlling the rate of traffic sent or received by web-servers.

Rate limiting works by recording the origin IP address and route information of an HTTP request on the server. This information would then be used for validating incoming HTTP request and blocking a duplicate request if it falls under the configured timespan. If a rule violation is detected, the configured wait period would then be extended to prevent request spamming (sliding window algorithm).

Rate-limiting can be implemented in both hardware and application layers. If you are a business that runs your application on infrastructure hosted by cloud providers like Windows Azure, you would want to utilize an application layer rate-limiting strategy.

In this article, we would utilize Ocelot framework to implement rate-limiting on top of an API gateway. Rate limiting is a sample of cross-cutting concern that you want to centralize and offload on API gateways. I've setup a project in GITHUB that you can use to follow and test the steps in the article.

Rate Limiting with Ocelot.

Ocelot offers a fine-grain way of specifying rate-limiting strategy per end-point. The code below showcases a simple way of declaring an endpoint that specifies a rate limiting strategy.

The code above specified the rate-limiting strategy through the "RateLimitingOptions" property. Below is a detailed explaination of the other sub-properties related to rate limiting strategy.

  • ClientWhitelist - List of client names that are exempted against the rate-limiting rule.
  • EnableRateLimiting - Flag that indicates whether the rule is enabled or disabled.
  • Period - Value that specifies the period that the limit applies to, such as 1s, 5m, 1h,1d and so on.
  • PeriodTimespan - Additional time that would be added on top of the existing wait time of a client if it issues a number of request that exceeded the configured limit on the specified Period value.
  • Limit - The count of HTTP requests allowed for the specified period value.

Global Rate-Limiting Configurations

We can also modify global rate limiting configurations (See example below)

  • DisableRateLimitHeaders - Property used for disabling / enabling X-Rate-Limit and Retry-After headers.
  • QuotaExceededMessage - Property that enables you to specify the message used for informing clients that the access quota was exceeded.
  • HttpStatusCode - Property that lets you specify which HTTP status code should be used to indicate Rate-Limiting violating response codes.
  • ClientIdHeader - Property used to specify the header that should be used to identify clients. By default it is “ClientId”

Testing the Configuration

If you try to navigate to the http://localhost:52793/api/transaction/getbyuserid/539bf338-e5de-4fc4-ac65-4a91324d8111 endpoint you will see the response below: There is nothing much special about the response provided by the server, however things get interesting when you try to hit the browser refresh button in quick successions (See result below):

Additional Thoughts

Rate limiting doesn't really assure a 100% defense rate against DDOS attacks but it increases the effort required to take down your system. Usually, you would want to combine this strategy with other defensive mechanisms to deter DDOS attacks such as blacklisting of IPs where abusive traffic originates.


Rate limiting reduces the risk of web-applications being attacked using denial of service attacks (DoS). Ocelot offers a fine-grain rate limiting strategy that can be applied specially for each API endpoint. In the next article we would start containerizing our downstream services and API gateway as a preparation for Kubernetes and Istio Service Mesh articles.

Related Articles

Get Razer from Amazon!

Cool Stuff for the Geeks


  1. Hi Allan,

    It's a nice article to create a our own Gateway using Ocelot, I am currently having an issue to add Cache layer to Ocelot GW. I mean i want to use my own custom class to cache the results.

    Please share your thoughts.

    1. Can you share me a sample C# project code with minimal stuff on it to replicate the issue?

  2. This blog is really helpful to deliver updated affairs over internet which is really appraisable. Cyber Security Brisbane

  3. Cybersecurity can play economic defense by protecting these jobs which deal with national security concerns and must remain the in the United States. Security Operations Center


Post a Comment

Popular posts from this blog

API Gateway: Response Aggregation with Ocelot and Core

Security: HTTP headers that expose web application / server vulnerabilities

API Gateway in a Nutshell

Building Simple API Gateways with Ocelot and Core