HAProxy acts as an API gateway in front of your application servers, providing cross-cutting security.


Using HAProxy as an API Gateway, Part 1 [Introduction]

Using HAProxy as an API Gateway, Part 2 [Authentication]

Using HAProxy as an API Gateway, Part 3 [Health Checks]

Using HAProxy as an API Gateway, Part 4 [Metrics]

Using HAProxy as an API Gateway, Part 5 [Monetization]


In almost every case, APIs have changed how modern applications connect to their data. Mobile apps, single-page web apps, IoT devices, integration hooks between software—all of these things rely on APIs to fetch, update, delete, and create data. In fact, one set of APIs might serve as the backbone of a website, mobile app, voice assistant device, and more, meaning one data store owns a treasure trove of information about us, the human users.

All of this to say that APIs are irresistible targets to would-be attackers. They would love to gain access to that data: to steal it, to categorize it, and to sell it.

In this blog post, we’ll discuss ways to improve the security of your APIs. We’ll see how placing your servers behind HAProxy and using it as an API gateway lets you narrow the point of entry for attackers. From this defensive position, you can build up your countermeasures. We will discuss the benefits of enabling authentication, TLS encryption, rate limiting, anomalous behavior protection, a web application firewall, and bot management in your API gateway.


Who should have access to your APIs?

Few APIs allow open access to anonymous users. Even free APIs that publish non-sensitive data will benefit from requiring some form of login. That’s because at the very least it gives you insight into how many distinct clients are using your services. It also makes it easier to rate limit specific users, even if they connect from multiple devices or IP addresses.

Authentication is the process of identifying who a user is. From a security standpoint, authenticating clients shrinks the attack surface. If only verified users have access, then there are fewer people who can abuse your services. You can also restrict authenticated users so that they have access to only a limited portion of your APIs, such as to give employees access to administrative functions that normal users shouldn’t see.

To authenticate users, sign up for an authentication service provider like Auth0 or Okta or install a service in-house. Authentication services take care of the login process and then give the client an access token, which they can use to gain access to your services. Services like Okta and Auth0 also provide APIs that let you automate signing up new users.

HAProxy sits in front of your APIs and acts as the gatekeeper, making sure that every client presents a valid access token. We described this workflow in our blog post Using HAProxy as an API Gateway, Part 2 [Authentication]. A client sends their token when making requests to your APIs and HAProxy validates it, checking that it has not expired, that it comes from a trusted authentication provider, and that it’s addressed to the expected recipient.

Because token validation happens at the API gateway, the servers behind the gateway don’t need to concern themselves with it. They only need to receive requests and send back responses. The gateway ensures that only users that are allowed to call your APIs are able to do so.

TLS encryption

API messages often carry confidential information that should be protected from eavesdroppers. They also carry a user’s secret access token if you’ve implemented authentication as described in the previous section. The way to protect this confidential information is to enable TLS encryption.

TLS stands for Transport Layer Security and it’s the cornerstone of all modern, secure APIs. It enables you to encrypt messages so that they can’t be read in-transit, while allowing only the receiver to decrypt them. Enabling it in HAProxy is straightforward. You simply need to upload your TLS certificate and private key to the server and then update your HAProxy configuration to use them to encrypt traffic. We explain the entire process in our blog post HAProxy SSL Termination.

TLS gives you several benefits. First, and perhaps most importantly, it prevents anyone from eavesdropping. Even if an attacker is able to intercept the messages, they won’t be able to decrypt them. TLS also maintains the integrity of the messages, since if an attacker tries to alter random parts of the requests, the client will become aware. It also gives the client a way to validate the server’s identity, since only the true server will possess the TLS private key that matches the API’s domain name.

By enabling TLS encryption in HAProxy, which acts as a gateway in front of your API servers, you offload that responsibility from your servers. This simplifies your application code and tightens your security by allowing you to store your TLS private key in fewer places.

Rate limiting

Rate limits put a cap on how many API calls a user can make within a period of time. They prevent a single client from overutilizing your application and network resources. After all, even an honest user may write a poorly written client application that makes too many requests. Yet, malicious users intent on flooding your service with requests are all too common. Without rate limits, one misconfigured client or malicious user can quickly overwhelm your services.

In our blog post HAProxy Rate Limiting: Four Examples, we demonstrated how HAProxy supports several types of rate limiting, each with its own set of knobs that you can use to tune the rate limit period, threshold, or fields that are used to identify a user: You can set the period to allow a certain number of API calls per second, minute, hour, or day; You can increase or decrease thresholds dynamically by using Map files, and you can identify users by a variety of things such as their IP address, URL parameter, or access token.

Rate limits set expectations for your customers about what fair use means. They’ll know that they can’t hammer your services incessantly, which allows them to plan ahead and weed out any misbehaving client code. Malicious users will be unable to abuse your APIs, for example by calling a function repeatedly to extract your entire catalogue of data.

Anomalous behavior protection

Once you’ve given a customer access to your APIs, it’s important that they use it only in the way that adheres to the terms of your agreement. For example, they should not try to discover or exploit vulnerabilities in your application. They should not try to circumvent your access controls, seek out restricted areas, or try dictionary-style attacks against your API endpoints.

You can detect anomalous behavior by making use of HAProxy’s stick tables and ACLs. Stick tables correlate a client’s actions across multiple requests, allowing you to verify that they’re authenticated, see how many successful vs unsuccessful responses they’ve received, observe how much data they’re uploading or downloading, check how many new connections they’re creating, and recognize when they’re scanning for vulnerabilities.

ACLs are complementary to stick tables. They’re the rules that trigger an action once you detect one of the aforementioned behaviors. For example, you might respond by denying that user’s request. Or, you might ban them for a time or simply log the event. We demonstrate many of the options available to you in our blog post Use HAProxy Response Policies to Stop Threats.

HAProxy Enterprise adds more safeguards. With the HAProxy Enterprise version, you can detect bot-like behavior and, through geolocation, check from where in the world the calls are originating. It can also verify that requests are coming from the types of devices you expect through its device detection modules.

Web application firewall

Many of the types of attacks launched against websites—including SQL injection and cross-site scripting—are directed against web APIs too. One way to protect yourself is to introduce a web application firewall (WAF) to inspect all incoming and outgoing traffic and filter out malicious messages.

HAProxy Enterprise ships with its HAProxy Enterprise WAF, which you can run in one of three modes. The simplest of the three modes, SQLi / XSS mode, guards against SQL injection and cross-site scripting attacks alone. This mode is quick to configure and requires very little maintenance, but will give you protection against two of the most common threats against web APIs.

In ModSecurity mode, the WAF blocks a wider range of attacks based on signatures defined in its ruleset files. You get protection against many of the top attack vectors including SQL injection, cross-site scripting, remote file inclusion, and remote code execution. This mode requires more tuning to get right, however it gives you leeway to add rules from various third-party vendors.

When operating in a high-stakes environment consider using the zero trust mode, wherein the WAF blocks all types of requests that have not been explicitly allowed. You might use this to protect APIs that connect critical systems within your organization where you know who the sender and receiver will be and exactly the type of messages they’ll exchange.

Protecting your APIs with a WAF is a smart move since it’s difficult to guarantee that the applications serving your APIs will always be 100% secure by themselves. A WAF stops attacks at the API gateway before they reach farther into your network.

Bot management

Attackers use bots to launch large, coordinated assaults against APIs. Bots automate the tedium of hacking. They can repeatedly invoke an API function to fetch all of the stored data; They can try endless combinations of values for a function’s parameter list, seeking the key that unlocks a vulnerability; They can attempt to inject code into as many endpoints as possible.

A bot does the boring work of hacking so that a human doesn’t have to. APIs are easy targets for bots because they are meant to be consumed by software anyway. There’s no web UI to get around, no text boxes to find and fill out, no buttons to click. An API is meant to be used by the machines.

The challenge with detecting malicious bots is that normal consumers of your APIs will also be software programs. Countermeasures like reCAPTCHAs and JavaScript challenges won’t be suitable since they would block legitimate software-based clients. However, all clients must follow your usage policy and those that don’t deserve to be dealt with in the same way.

HAProxy comes with mechanisms for detecting whether a client is behaving badly. In our blog post Bot Protection with HAProxy, we give examples of bots that make thousands of requests to unique URLs in order to scan your service for vulnerabilities. Other bots will call the same URL many times, such as to try to brute force their way past your authentication mechanisms.

You can discover bad behavior with anomalous behavior detection, as we described earlier. The rate limits we described earlier will also stop clients that make too many requests within a period of time. In the end, when all clients are expected to be machines, you have to fall back to treating them all with the same rules. An API gateway is the best place to enforce these rules.

With HAProxy Enterprise, you can aggregate the stick table data from multiple API gateways. That makes it possible to identify behaviors even when a bot’s requests are routed to multiple nodes in an active/active cluster. This gives you the full picture of the volume and character of the requests.


In this blog post, you learned several ways to protect your APIs using an API gateway. By layering on authentication, TLS encryption, rate limiting, anomalous behavior protection, a WAF, and bot management you can stop attackers before they reach your servers. Having this level of security for your APIs is more important than ever as more types of applications rely on APIs to connect to their data. Having it all in one place means you can provide that security across your entire catalogue of services.

Interested in learning what HAProxy Enterprise has to offer? Contact us to learn more.

Want to know when more content like this is published? Subscribe to our blog and follow us on Twitter. You can also join the conversation on Slack.