All DDoS Definitions
DDoS Testing Definition

False-Positive Rate

False-positive rate measures the share of legitimate traffic that a mitigation control wrongly blocks or challenges. Under attack the number tends to rise at the worst moment, because emergency rules get tightened exactly when real users are trying hardest to get through, which is why a DDoS test reports it beside the false-negative rate, the share of attack traffic that slips past. Either figure alone flatters the control; the pair shows the trade it is actually making.

False-positive rate: real users caught in the filter Incoming traffic legitimate users + attack flood Mitigation control rate limit, WAF, bot mgmt threshold set here Allowed to origin real users served Blocked attack blocked (intended) legit blocked = false positives A test drives real traffic alongside the attack, then measures how many genuine requests the active rules drop. BlackNeuron™
Diagram of false-positive rate: a mitigation control blocking the attack while wrongly rejecting some legitimate users as collateral

Why the denominator matters

The rate is calculated over legitimate requests only: real requests wrongly blocked, divided by all real requests. That sounds obvious until a dashboard reports "99 percent of traffic blocked" during an attack. When the flood is a hundred times larger than the user base, a control can block 99 percent of everything and still turn away one real user in five, and the headline number barely moves.

Production cannot calculate it reliably either. A blocked request leaves a log line, not a label, and nobody knows afterwards whether that address was a bot or a customer. Estimates come from complaints, support tickets and conversion dips, all of which arrive late.

Where false positives come from

Most collateral comes from a handful of patterns. Per-IP rate limits punish shared addresses: a mobile carrier's carrier-grade NAT or a corporate egress proxy can put thousands of people behind one IP, so a threshold tuned for one person blocks an office.

Challenges fail whole classes of client. A JavaScript challenge works in a browser and returns a page that no API client, mobile SDK or payment webhook can solve, so for that traffic an emergency challenge rule has a false-positive rate of effectively 100 percent. Geo-blocks catch travellers and VPN users, and reputation lists catch whoever inherited a recycled address.

This is why a rule should spend time in count mode before it enforces. Counting shows what the rule would have matched against real traffic, which is the closest production gets to a measured false-positive rate.

False-positive rate: the dip real users feel when a rule tightens normal success rate legitimate requests served time across an attack before the attack emergency rule blocks real users too rule tuned per client class attack filtered, users served The attack is blocked throughout; the depth of the dip is collateral, and that is the false-positive rate BlackNeuron™
Animated false-positive rate: legitimate requests served dip when an emergency rule starts blocking real users along with the attack, then recover once the rule is tuned per client class

Why it matters under attack

Every threshold is a point on a trade. Tighten a rate limit from 100 requests a minute to 20 and the false-negative rate falls, because fewer attack requests fit under the line. The false-positive rate climbs at the same time, because the heaviest real users, and every shared address, now cross it. Loosen it and the two numbers move back the other way. There is no setting that drives both to zero, only a choice about which error the service can afford during this attack.

Not every false positive is a block. A challenge that takes eight seconds to load, or a queue that holds a request past the client's 10-second timeout, fails the user just as surely as a 403 does, and it never shows up in the block log. Those soft failures belong in the count.

Blocked clients also come back. A mobile app or SDK that gets a 429 usually retries, often several times, so a rule that wrongly rejects real traffic can add load at the edge instead of shedding it. A high false-positive rate is a cost to users and, through the retries, a cost to the control itself.

What a DDoS test measures

A test has the one thing production lacks: ground truth. It generates its own legitimate traffic, from realistic client types and address patterns, alongside the simulated attack, so every request it sends is known to be real or attack. Counting how many of the real ones were blocked, challenged, or slowed past a client timeout gives the rate directly instead of as a guess.

The useful output is that rate per control and per client class, at each threshold under consideration, before and after emergency rules engage. A rule that holds 0.1 percent for browsers while blocking every API call is not a 0.1 percent rule. What that means for choosing where an enforcement threshold sits is worked through in Application-Layer (L7) DDoS Testing.