Doubling Throughput: Bypassing Endpoint Rate-Limiting via Path Traversal Slashing

Rate limiting at the authentication layer is an essential control to thwart automated credential-stuffing and brute-force attacks. However, if defensive logic treats nearly identical routing paths as separate resources, the restriction can be broken.

During an assessment of a target's authentication endpoint, I discovered a mechanism that tracked brute-force attempts globally based on the attacker's IP address. While IP rotation was theoretically possible, many bug bounty programs reject pure IP-rotation findings as low-severity or out-of-scope. I needed a way to scale my attack speed using a single static IP without triggering the restriction.

By analyzing how the application's reverse proxy handles routing rules, I successfully doubled my attack throughput by abusing an extra trailing slash.

The Infrastructure Logic Flaw

The target monitored brute-force behavior at the primary login path: /login.

The core flaw rested in a discrepancy between the Rate Limiter and the Application Router:

1. The Rate Limiter tracked request frequencies against exact URL string keys. It was strictly configured to allow a maximum execution speed of 4 threads per second on the literal string /login.

2. The Application Router normalized incoming paths. To the backend application server, both /login and /login/ (with a trailing slash) mapped to the exact same authentication controller logic.

Because the rate limiter treated these paths as completely distinct endpoints, it maintained a separate independent bucket for each variation.

Crafting the Multi-Path Exploitation

Since the rate limiter capped single-endpoint speed at 4 requests per second, executing 5 or more concurrent threads on /login instantly resulted in an HTTP 429 (Too Many Requests) block.

To bypass this without rotating my IP address, I designed an attack scenario that split the dictionary load evenly across both routing variations simultaneously.

Steps to Reproduce

1. Capture the Request: Intercept the legitimate login payload (POST /login HTTP/1.1) and pass it to Burp Suite Intruder. Configure the attack speed limits strictly to 4 threads per second.

2. Clone and Modify the Path: Send the identical request payload to a second Intruder tab. In this configuration, append a trailing slash to the path (POST /login/ HTTP/1.1). Set this tab's restriction to 4 threads per second as well.

3. Execute Concurrent Attacks: Launch both Intruder instances simultaneously.

Impact & Rating Update

By exploiting this path-traversal behavior, I circumvented the rate-limiting threshold—effectively achieving a combined throughput of 8 threads per second from a single IP address without triggering an alarm or denial-of-service block. This significantly shortens the time required to successfully execute a high-velocity credential-stuffing attack.

Security Analysis

The finding exposed an architectural disconnect: the security control keyed requests by their literal path while the application normalized both paths to the same authentication handler.

The practical result was a twofold increase in permitted request throughput from one source address. Defenders should canonicalize routing inputs before applying rate-limit keys and test equivalent path forms against one shared quota.

For more insights into web routing flaws and rate-limit bypass techniques, follow my research on Twitter: @siratsami71.