Unlike a block rule, a challenge-response control does not decide a suspicious request's fate on what it has already seen; it asks the client to do something and decides on the answer. It is a Layer 7 defensive control, and how well that question separates people from automation under load is what a DDoS test measures. When a request looks suspicious, the edge interposes a test the client must pass before traffic reaches the origin: a silent JavaScript challenge, an interactive CAPTCHA, or a proof-of-work puzzle. Each of those has its own page; this one covers what they share.
How the exchange works
Every variant follows the same three steps. The edge receives a request it does not trust, and instead of forwarding it, serves an interstitial response from the edge itself, so the origin does no work. The client performs the task and submits the answer. If the answer verifies, the edge issues a clearance token, usually a signed cookie with an expiry, and replays or redirects the original request.
That token is the part people forget. One solve buys many requests: every request carrying a valid clearance skips the challenge until it expires. So the security of the whole scheme rests on two settings. How long the clearance lasts, and what it is bound to. A token bound only to itself can be solved once by a real browser and then copied to thousands of bots, which present it from anywhere. A token bound to the source address or the TLS fingerprint resists that, at the price of re-challenging real users whose phone changes networks mid-session.
The other shared property is that the challenge only works where something can render it. An interstitial page means nothing to a fetch() call inside a single-page app, a native mobile client, a form POST, a webhook from a payment provider or a server-to-server API call. Challenge those and they break. Exempt them and the exempt path becomes the obvious way in for a flood.
Why it matters under attack
A challenge is the middle setting between doing nothing and blocking, which is why it is the default response to uncertainty in most WAF and bot-management stacks. Its value in a flood comes from moving the work to the edge: a challenged request costs the origin nothing, and an unanswered challenge costs the attacker a round trip that produced nothing.
The weak points are the ones above, seen from the attacker's side. Headless browsers answer JavaScript challenges natively. Solving services answer CAPTCHAs for a fraction of a cent. A single harvested clearance token, if it is not bound to anything, turns one solve into a whole botnet's pass. And any API path that cannot be challenged is a path that has to be defended some other way.
What a DDoS test measures
The most useful number a test produces here is the challenge solve rate: of the challenges issued, what share came back answered. In normal traffic it should be high, because the challenged clients are mostly people. During a flood it should collapse toward zero, because the challenged clients are mostly scripts. A solve rate that stays high during an attack means one of two things, and the test has to say which: the attacker is solving (headless browsers, solvers, replayed tokens), or the trigger is challenging your own users while the flood arrives on a path that is never challenged.
Alongside it, a test reports when the challenge engages relative to the origin's saturation point, whether a clearance token can be replayed from another address, how long a token lives, and which endpoints are exempt and what protects them instead. The control fails differently on browser pages and on machine-to-machine calls, and the API side of that is one of several places where request count stops describing load, which DDoS testing for APIs sets out in full.