Discovering and securing any API is one of the most difficult challenges for developers. The API security landscape is constantly evolving, with new threats and vulnerabilities emerging at a rapid pace. Since commercial API security solutions can be expensive for some organizations (especially 1-person or micro shops), it’s never a bad idea to look at open-source alternatives. The open-source API Firewall is the pioneer in this space with more than 1 billion docker pulls since its first release in October 2021. This article will discuss its new feature: default deny lists (or blocklists) for compromised API tokens and cookies.

1. Why do API token leaks happen?

When an API server is not properly secured, it could leak its tokens to the internet. Bad guys could intercept traffic to the server and use the leaked tokens to authenticate themselves and access the API.

There are multiple ways this could happen, such as:

  • The API is accessed by a third-party application, either on the same or a different server.
  • The API is accessed by another service that is directly exposed to the internet (not using TLS).
  • The API is accessed by a service that is using an unsecured internal load balancer.

2. Are default deny lists of compromised credentials and API tokens the solution?

Blocklists have been used for many years to block known bad guys from accessing specific websites or IP addresses. The general idea is to blocklist known malicious IP addresses or domains that are associated with attacks, and let through everything else. However, this approach can create other problems. 

To start with, a lot of companies create their own blocklists and share them with their clients in an effort to keep them safe, which is difficult to keep on top of and maintain. It’s also hard to block *all* tokens on all *endpoints*. In addition, blocklists are prone to false positives, where an address or user is erroneously marked as malicious when they aren’t, which adds to the administrative burden. In short, blocklists are only as good as the rules that create them and the maintenance effort expended to stay on top of them.

3. Using open-source API Firewall to prevent using leaked tokens and cookies.

If an API leak is detected, the open-source API Firewall is able to stop the affected tokens and cookies from being used. The firewall will set a policy to block all traffic from the offending API service, ensuring that the breach is contained. The firewall is able to add the detected tokens and cookies to the blocklist. This means that all new compromised tokens and cookies will be blocked in any form, to prevent them from being used as authentication secrets and compromising your APIs.

To enable this policy, users can just put compromised tokens into the blocklist file in a plain text format. Like this:


And then apply it by the following ENV variable or CLI argument:


Then determine which HTTP header or Cookie name should be used to find token value:


If the compromised API is using JWT, it’s also possible to trim the JWT prefix by setting the variable APIFW_DENYLIST_TOKENS_TRIM_BEARER_PREFIX to the value true or false.

Then all the requests with blocklisted tokens or cookies will be blocked by open-source API Firewall:

curl http://localhost:8080/anything -v -H "Cookie: test=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzb21lIjoicGF5bG9hZDk5OTk5OTEifQ.NdeEQYz4vE56uJrniAHCDO2NeMJmlrUH5F_a5bQJOo4"


The open-source API Firewall by Wallarm is a great option for API development. It offers a rich feature set, and its underlying technology is mature. The firewall’s new feature of blocklisting for compromised tokens and cookies is a great way to gain visibility into threats and prevent issues. The feature is easy to set up and offers a high degree of visibility into the security posture of your APIs and services.