WAFs miss credential-stuffing bots when requests look legitimate

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Kasada's blog post: Credential-stuffing bots can evade WAFs because their requests look valid and their traffic rotates across residential proxies.

Why it matters: IAM and application-security teams need to separate exploit filtering from bot detection, because login abuse is increasingly judged by sender identity and behaviour rather than request content alone.

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.

Context

A web application firewall inspects request content for exploit patterns such as SQL injection or cross-site scripting. That model breaks down when the request itself is clean but the actor behind it is automated, credential-driven and trying to look like a normal user.

Bot mitigation exists to answer a different question from a WAF: whether a real person, a browser session or an automated tool is behind the request. In identity and access terms, that shifts the control point from payload inspection to sender assurance and behavioural risk assessment, which is why the distinction matters for login, signup and checkout flows.

Key questions

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. They use stolen credentials, real browser sessions and distributed source IPs, so a WAF sees ordinary form traffic rather than malicious content. Detection has to shift from request inspection to sender and behaviour analysis.

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. That makes IP-based throttling, reputation scoring and simple per-address blocks far less effective. Defenders usually need device fingerprinting, behavioural analysis, session correlation and per-account controls, not just IP rate limits.

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. Bot controls focus on client behaviour, device signals and session abuse, whereas a WAF focuses on HTTP payloads, signatures and application-layer attack patterns such as injection and traversal.

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.

Technical breakdown

Why WAF rules miss credential stuffing

A WAF is designed to inspect request syntax and payloads for exploit signatures, anomalous parameters or obvious malicious content. Credential stuffing usually avoids those triggers by using valid form fields, real usernames and passwords stolen elsewhere, plus normal browser flows. The request is not malformed, so signature-based and rule-based inspection has little to match. That makes login abuse a sender problem rather than a payload problem, especially when attackers distribute attempts across many IPs and sessions. See the Web Application Attacks Guide.

Practical implication: Treat login abuse detection as a separate control plane from exploit filtering and design for sender risk, not just payload inspection.

Residential proxies and rate limits

Per-IP rate limiting assumes attack traffic clusters around a small number of addresses. Residential proxy networks break that assumption by distributing requests across many home IPs with clean reputations, making volume controls look normal until abuse is already under way. In practice, the attacker is no longer identifiable by source address alone, so network reputation becomes a weak signal when used in isolation. See the Bot Management Guide.

Practical implication: Use rate limits as a floor, not a decision control, and pair them with browser and session signals that survive IP rotation.

Client-side proof of execution

Bot mitigation shifts part of the test into the browser or app itself. The platform can run code that is difficult for automation frameworks to fake, then use the results to tell whether the client behaved like a real environment. That creates friction for attackers because they must emulate a full browser or device stack instead of simply replaying requests. The control is strongest when it evaluates the first request, before the bot reaches the protected workflow.

Practical implication: Move enforcement to the edge of the session and require signals that prove the client actually executed the challenge.

Threat narrative

Attacker objective: The attacker wants to turn valid but stolen credentials into authenticated access at scale while keeping each request indistinguishable from legitimate customer traffic.

1. Entry begins with stolen usernames and passwords that are replayed against login endpoints using automation rather than interactive sign-in.
2. Credentialed requests are distributed through residential proxies and real browser tooling so per-IP controls and simple reputation checks do not separate attack traffic from normal users.
3. Successful logins create account takeover opportunities that can be used for fraud, scraping, checkout abuse or further credential testing across other services.
4. Impact is measured in unauthorized access, customer friction from false positives and operational noise as teams chase attacks that look ordinary at the request layer.

Breaches seen in the wild

• Imperva breach 2019: An AWS API key stolen from an exposed Imperva test instance let an attacker copy Cloud WAF customer data, including API keys and SSL certificates.
• Capital One breach 2019: A misconfigured firewall handed over its cloud role credentials, and an over-privileged role exposed data on 106 million people.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Residential proxy traffic creates a verification gap, not just a volume problem. When attackers spread attempts across many household IPs, rate limiting becomes a blunt throttle rather than a reliable signal of malice. The more important question is whether the browser, device and session behave like a genuine customer context, which is why bot mitigation belongs alongside account protection controls.

Request legitimacy is not user legitimacy: this is the named governance gap that credential stuffing exploits. Organisations often assume that a syntactically valid login attempt is sufficient evidence of a real user, but automation, stolen credentials and proxy rotation break that assumption. The implication is straightforward: security decisions must move from request content to actor assurance.

AI is accelerating bot adaptation faster than rule-writing can keep up. As toolkits gain AI-assisted configuration and evasion, static rules age quickly and become maintenance-heavy. The market signal is that bot defence is moving toward continuously updated detections and behavioural proofs rather than bespoke rule libraries. Practitioners should expect a shorter control half-life and plan for that operational reality.

What this signals

Bot detection is becoming an identity problem at the edge. When login abuse is driven by stolen credentials and proxy rotation, defenders are no longer just inspecting requests, they are assessing whether the actor behind the session is trustworthy. That pushes security teams toward controls that combine device, browser and behavioural evidence rather than relying on network reputation alone.

WAF and bot controls will keep converging operationally, but not conceptually. The WAF remains the payload filter and the bot layer becomes the sender filter. Practitioners should expect their most important decisions to move toward where the request is coming from, how it behaves and whether the client can prove execution, especially on monetised identity flows.

For practitioners

• 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.
• Test monitoring mode against real abuse cases Measure whether your current bot rules are only being watched rather than blocked, then check false positives on real customer journeys before moving policy into enforcement.

Key takeaways

• Credential stuffing succeeds when defenders treat valid-looking login traffic as proof of legitimacy, not merely as proof that a request was syntactically clean.
• Residential proxy use and AI-assisted tooling make this abuse harder to suppress with static WAF rules or per-IP throttles alone.
• Practitioners need separate controls for exploit filtering and bot detection, with sender assurance applied before authentication or checkout succeeds.

Related NHI Mgmt Group resources: Web Application Attacks Guide · Bot Management Guide · Magic Links and Email OTP Security Guide

Key terms

• Credential Stuffing: Credential stuffing is an attack that uses stolen username and password pairs from previous breaches to try logging into other services. It works because many people reuse credentials, and because the login attempt uses valid information, it can look ordinary until the surrounding behavior gives it away.
• Residential Proxy: A residential proxy routes traffic through an address assigned to a real consumer device or household connection. That makes the traffic look more legitimate than datacentre-based proxies, which is why abuse actors use it to bypass reputation checks and blend into normal user traffic.
• Bot mitigation: Bot mitigation is the use of behavioural, device, and session signals to distinguish automated traffic from legitimate users. In fraud-sensitive workflows, it is a pre-action control that must decide whether a request is allowed to reach a chargeable or privileged step.
• Web Application Firewall: A web application firewall inspects HTTP traffic and applies rules to detect or block malicious requests and responses. Unlike a network firewall, it understands application-layer content such as headers, parameters, and body fields, which lets it catch attacks like injection and path probing.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity controls to the broader security programmes they run across cloud, application and operations.