API Security

Open-Source API Firewall Unveils New Feature: Default Deny Lists for Compromised API Tokens and Cookies

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:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzb21lIjoicGF5bG9hZDk5OTk5ODIifQ.CUq8iJ_LUzQMfDTvArpz6jUyK0Qyn7jZ9WCqE0xKTCA
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzb21lIjoicGF5bG9hZDk5OTk5ODMifQ.BinZ4AcJp_SQz-iFfgKOKPz_jWjEgiVTb9cS8PP4BI0
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzb21lIjoicGF5bG9hZDk5OTk5ODQifQ.j5Iea7KG

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

APIFW_DENYLIST_TOKENS_FILE

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

APIFW_DENYLIST_TOKENS_COOKIE_NAME and APIFW_DENYLIST_TOKENS_HEADER_NAME.

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 https://localhost:8080/anything -v -H "Cookie: test=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzb21lIjoicGF5bG9hZDk5OTk5OTEifQ.NdeEQYz4vE56uJrniAHCDO2NeMJmlrUH5F_a5bQJOo4"

Conclusion.

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.

Recent Posts

Stop Reviewing Your AI Agents. Start Governing Them.

Brookings and the World Economic Forum say agent governance must be continuous, scoped in advance,…

2 days ago

You Can’t Secure the AWS Accounts You Don’t Know About.

Wallarm Infrastructure Discovery Named Enterprise Cloud Security Solution of the Year. Ask an AWS security…

2 weeks ago

AI Governance on AWS: The Runtime Control Loop: AI Governance on AWS: Four Functions, One Loop, and a Deadline That Already Passed

Answer this without checking: how many AI agents are running in your environment right now?…

3 weeks ago

AI Agent Security Readiness: The Federal Standard You Should Get Ahead Of

Here's the uncomfortable part first: in August 2026, researchers found AI agents connected to Hugging…

1 month ago

Dissecting Attacks Is Only Valuable If It Informs Controls: What the Unit 42 agentic AI investigation should change in your control set, stage by stage.

The volume of published incident research involving agentic AI is increasing, and the analysis that…

2 months ago

Lessons from the OpenAI and Hugging Face Incident: When Safety Filters Disarm the Defender

In July 2026, an OpenAI model escaped its evaluation sandbox and broke into Hugging Face's…

3 months ago