How We Defended Our API Against a Sophisticated Layer 7 Botnet

It started on a Tuesday night. Our database CPU spiked to 98%, and legitimate users were getting timeouts. I assumed a viral marketing post caused a traffic spike. But when I looked at the logs, the requests were perfectly timed, evenly distributed, and specifically targeting our most expensive search endpoints. We were under a Layer 7 distributed attack.

Why Traditional Rate Limiting Failed

My first reaction was to apply IP-based rate limiting. It did absolutely nothing. The attackers were using a massive pool of residential proxies. By the time an IP hit our rate limit threshold, the bot rotated to a new IP in a different country. Blocking by IP was like playing whack-a-mole with a blindfold.

Behavioral Signatures, Not IPs

We had to stop looking at who was making the request and start looking at how the request was made. We analyzed the headers and noticed a subtle pattern: the bots were sending a perfectly valid Chrome User-Agent, but their TLS fingerprint (JA3 hash) corresponded to a known Python requests library.

We deployed custom Cloudflare WAF (Web Application Firewall) rules that blocked requests where the declared User-Agent clashed with the underlying TLS fingerprint. Instantly, 40% of the malicious traffic dropped.

Implementing the "Proof of Work" Challenge

For the remaining highly sophisticated bots (those using actual headless browsers), we implemented a friction layer. Before accessing the search endpoint, the client had to silently execute a small JavaScript proof-of-work challenge and return a token.

Legitimate browsers completed this in 50 milliseconds silently. The bots, optimized for pure scraping speed and lacking a full JS runtime in some cases, failed the challenge or abandoned the request rather than waste compute cycles.

The lesson? Hackers are well-funded and intelligent. Hardcoded IP blocks are a relic of the past. You must defend your API using behavioral analytics and cryptographic friction.