A CoAP amplification attack is a Layer 4 (UDP) reflection vector that produces volumetric Layer 3 saturation, one of the reflection classes a thorough DDoS test is built to exercise. It abuses the Constrained Application Protocol (RFC 7252), a lightweight request and response protocol that IoT and embedded devices speak over UDP port 5683. The attacker sends a small CoAP request with the victim's address forged as the source, and the exposed device answers the victim with a response many times larger, so a modest stream of spoofed queries lands on the target as a large flood.
How CoAP amplification works
CoAP was designed for devices with tiny memory and power budgets, so it rides on connectionless UDP and keeps its framing minimal. That is precisely what makes it reflectable. UDP performs no handshake, so a device cannot confirm that the source address on a request is genuine: it simply replies to whatever address the packet claims to come from. When the attacker forges the victim's IP, every reply is delivered to the victim rather than the sender. This is the same source-address-validation failure that underpins every UDP reflection vector, from DNS to NTP.
The size gap between question and answer supplies the amplification. A GET to a discovery resource such as /.well-known/core, which many CoAP stacks expose by default, returns a resource listing far larger than the query that triggered it, and CoAP features like block-wise transfer and non-confirmable (NON) messaging can widen the gap further. Reported amplification factors cluster in the tens, enough that a single reflector converts one byte of attacker bandwidth into tens of bytes aimed at the target.
Why the reflector pool is large and renewable
What makes CoAP dangerous in practice is not the per-device factor but the population behind it. Millions of consumer IoT devices ship with a CoAP endpoint reachable from the public internet, many sitting behind carrier NAT that still forwards UDP 5683, and most are never patched across their service life. That yields a large, self-renewing pool of reflectors an attacker enumerates the same way a researcher does: a UDP scan for hosts that answer on 5683. Because the packets hitting the victim originate from thousands of unrelated, legitimate device addresses rather than from the attacker, source blocklists accomplish little, and the spoofing-capable infrastructure that seeds the attack stays hidden behind the reflectors.
This overlaps with the IoT botnet problem without being identical to it. A botnet floods you with compromised devices under an operator's control; a reflection attack floods you with uncompromised devices that are merely answering forged questions. The same device fleet can play both roles, which is why volumetric-vector coverage cannot stop at the specific flood types a given botnet is known for. An attacker who loses one reflector class simply scans for another.
What a DDoS test measures
CoAP amplification saturates a link, so the control under test is not the origin application but everything upstream of it: transit capacity, the scrubbing center that absorbs and filters the flood, and how quickly diversion engages before the access link fills. A test drives a controlled volumetric load shaped like reflected UDP and measures absorption headroom and time to mitigation, not whether the origin can parse a CoAP message it will never legitimately receive from the public internet.
Because the structural fix, source-address validation (BCP 38) at the networks that let spoofed packets escape, sits with carriers rather than the target, defense here is a question of absorption rather than prevention. Testing therefore centers on what the target actually controls: whether upstream scrubbing recognizes the reflected pattern, whether there is enough transit headroom to ride out the peak, and whether mitigation cuts over fast enough that saturation never reaches goodput collapse. For the full reflection family and how these vectors combine in a real event, see Understanding DDoS Attack Vectors.