Rediscovering a Rate Limit Bypass: Cookie Header Strikes Again

The discovery and what caught my attention

During a recent assessment, I ran into a rate limit issue that felt familiar but still surprising in its own way. The API I was testing had a typical rate limiting setup to slow down repetitive or aggressive traffic. After reaching the limit, I noticed something unexpected. If I replaced the Authorization Bearer token with a Cookie header, the system allowed me to continue making requests. The cookie did not need to match a real session. It simply needed to look like a proper cookie.

A simple swap with unintended results

Once the rate limit kicked in, the system responded with the usual error codes such as 302, 400, and 429. But as soon as I added the Cookie header, everything changed. Requests that should have been blocked were now going through without resistance. It did not matter that the rate limit had already been reached. The presence of the cookie alone was enough to let the traffic flow again.

Trying to understand what was happening

Without access to the backend, I can only share ideas based on past experience and what I observed during testing. Here are a few possibilities that may explain why this worked:

1. Session context override. Some systems tie rate limits to session identifiers. By switching from a token to a cookie, the request might have been treated as coming from a different session entirely.
2. Fallback between authentication methods. When a system supports both token-based requests and cookie-based session handling, one type of authentication may unintentionally take priority over the other. The cookie may have shifted the system into a different logic path where the rate limit was not enforced the same way.
3. Confusion in the rate limit key. Many rate limiters use a combination of headers and identifiers to track usage. Adding the cookie may have altered that key enough to make the server think it was receiving traffic from a different source.
4. Mixed response code behavior. The different response codes I saw suggested that requests were being handled through slightly different logic branches depending on the headers present. This usually means inconsistent session handling somewhere in the chain.

Why this matters more than it first appears

At first glance this type of bypass might seem small, but it can allow for several problematic behaviors:

• Uncontrolled request volume. Someone could make far more requests than intended and collect much more data than the system is designed to expose at one time.
• Brute force attempts. If rate limits can be avoided, the door is open for repeated password or credential testing.
• Strain on backend systems. Allowing unlimited calls can slow down or even disrupt services for real users.
• Unwanted data harvesting. Excessive data scraping becomes much easier when limits can be ignored.

A pattern I have seen before

This was not the first time I found a rate limit bypass related to cookies. In a previous assessment, I discovered that combining a session cookie with an OAuth token opened the door to bypass rate limits in a different way. This time it required even less. A simple swap between a token and a cookie was enough. Whenever multiple authentication methods exist side by side, it becomes easy for small gaps to appear between them.

A quick reflection

I do not see this as a mistake by the development team, but more as one of those tricky interactions that happen when a system evolves over time. Small pieces of logic can collide in ways nobody expects. Finding these issues helps strengthen the system and gives everyone a clearer picture of how the service behaves in real conditions.

The mind map

The diagram below is how I tracked the relationships between the different cookies, tokens, and bypass paths as I worked through this.