Topic starter
06/11/2026 6:55 pm
TL;DR: Login abuse can pass straight through WAF controls when attackers use stolen credentials and residential proxies, according to Kasada's analysis of bot traffic. Practitioners need controls that evaluate the sender, not just the request payload, because exploit detection alone will miss this class of abuse.
Editorial analysis by NHI Mgmt Group, based on content published by Kasada: “Bot mitigation vs WAF. Can a WAF stop bots on its own?”.
By the numbers:
- Kasada's Q3 2026 threat report found talk about using AI to reverse engineer anti-bot scripts grew 19x since Q1.
- In Kasada's 2024 State of Bot Mitigation survey, 67% of companies relied on traditional CDN-based bot management, and only 20% said their bot protection stayed effective for a year or more after deployment.
Key questions
Q: Why do residential proxies weaken rate limiting?
A: Residential proxies weaken rate limiting because they spread automated requests across many consumer IP addresses that look like ordinary household traffic.
Q: How do bot management and a web application firewall differ?
A: Bot management detects and classifies automated traffic, while a web application firewall inspects requests for known web attacks and policy violations.
Q: How do bots bypass WAF controls on login pages?
A: Bots bypass WAF controls on login pages by sending valid-looking requests that contain no obvious exploit payload.
Practitioner guidance
- Separate login abuse from exploit filtering Keep WAF policy focused on injection and request-level exploits, then run bot detection on login, signup, checkout and other monetised flows where valid credentials can be abused.
- Reduce dependence on per-IP blocking Assume residential proxies will fragment source reputation across thousands of addresses, and make sure your detection stack can score browser and session behaviour without relying on IP history.
- Require client proof before allowing high-risk flows Use signals from the browser or app that are hard for automation frameworks to spoof, and enforce them before authentication succeeds or the workflow reaches a purchase decision.
Bottom line: Credential stuffing succeeds when defenders treat valid-looking login traffic as proof of legitimacy, not merely as proof that a request was syntactically clean.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:56 pm
WAFs are the wrong control for sender impersonation. A WAF can still be useful for exploit blocking, but credential stuffing is a different class of abuse because the request content is often clean. That means the control failure is not weak filtering, it is using payload inspection to solve a sender-verification problem. Practitioners should treat login abuse as an identity-adjacent risk that needs separate detection logic.
A question worth separating out:
Q: How should teams reduce false positives in bot protection?
A: Teams reduce false positives by tuning bot controls with allow lists, challenge thresholds, behavioural scoring and exception handling for legitimate automation. They should correlate signals such as user agent, session continuity, device fingerprint and request velocity, then review challenged flows against real business traffic so that human users and approved bots are not blocked unnecessarily.
👉 Read our full editorial: WAFs miss credential-stuffing bots when requests look legitimate