Most teams learn the limits of their DDoS protection during a real attack. That is the worst possible time to find out that a WAF rule was too loose, or that an origin server was never shielded at all. Knowing how to test your DDoS protection before an incident is the difference between a controlled finding and a public outage.

This guide is written for the people who own that risk at a regulated institution: security engineers, WAF and load-balancer operators, and the compliance officers who have to prove resilience to a regulator. It covers what a proper test measures, how to run one without knocking yourself offline, and how to turn the result into evidence an auditor will accept.

What testing your DDoS protection actually means

A DDoS test sends controlled, realistic attack traffic at infrastructure you own, then measures whether your defenses absorb it and how your service behaves while under load. The goal is not to break the site. It is to find the point where protection degrades, so you can fix it on your own schedule.

Two things it is not:

• It is not a booter or stresser. Those services fire anonymous traffic at arbitrary targets. They are illegal to point at anything you do not own, and they give you no measurement, no authorization trail, and no report.
• It is not ordinary load testing. A load test asks “can we serve 10,000 legitimate users?” A DDoS test asks “what happens when the traffic is hostile, malformed, or shaped specifically to exhaust a resource our load test never touches?” Different traffic, different failure modes.

The value is in the specificity. A good test tells you which layer failed, at what volume, and whether your mitigation triggered in time.

Authorization comes before the first packet

The single rule that separates legitimate resilience testing from an attack is authorization. You test only assets you own or are explicitly contracted to test, and you prove that ownership before any traffic flows.

Obsidio enforces this with DNS TXT ownership verification. You place a record on the domain you intend to test, and no simulation can start until that record is confirmed. Runs are controlled, ramped up gradually, and can be aborted live. This is what makes the exercise defensible to a legal team and repeatable for a compliance file: the authorization is recorded, not assumed.

Treat this as the first control you are testing, not a formality. If your own change-management process cannot produce a signed-off, time-boxed authorization for a test, it will not produce one for an incident either.

The attack types worth testing against

DDoS is not one thing, and protection that stops one class can be blind to another. A test programme should exercise the distinct ways a service fails. Obsidio’s simulation catalog spans four categories, each stressing a different part of your stack:

• Application-layer floods (Layer 7). HTTP Flood drives high volumes of well-formed requests at the application path: the request queue, the app threads, and the database behind them. Goldeneye appends randomized query strings so every request bypasses the cache and reaches the origin, with rotating browser-like headers. Browser Flood uses real browser sessions that load the full page and every sub-resource, producing traffic that is hard to separate from genuine users. Apache Killer sends overlapping Range headers (CVE-2011-3192) that force a vulnerable Apache build to allocate the response body many times in memory, a low-rate request that can exhaust an unpatched server.
• Slow attacks. Slowloris holds many connections open by trickling partial requests, exhausting the connection pool at almost no bandwidth. RUDY opens slow POSTs that advertise a real content length then send the body one byte at a time, pinning request-handler workers. Both probe connection handling and timeout configuration, a common blind spot for volume-focused defenses.
• Connection exhaustion. TLS Flood completes the full TLS handshake, making the server pay the asymmetric-crypto cost, then drops the socket. TCP Connection Flood opens raw connections and holds them idle to exhaust the connection table, file descriptors, and accept queue. These test capacity limits that a request-rate defense never sees.
• Protocol-specific and scripted. DNS Flood sends raw DNS queries over TCP, one connection per query, stressing resolver CPU and TCP-listener resources. Puppeteer Script runs a scripted real-browser user journey (login, form submit, an end-to-end flow) under concurrency, for functional and synthetic-user load rather than raw request rate.

The catalog grows as attacker techniques do. For a first test, aim for coverage across categories: at minimum one application-layer flood and one slow or connection-exhaustion attack, because they fail different parts of your stack.

A method you can repeat: Configure, Test, Adapt, Retest

A single test is a snapshot. Resilience is proven by the loop. Obsidio structures each run in four stages:

• Authorize. Verify domain ownership via DNS TXT before anything runs.
• Configure. Choose the simulation type, scale, geographic distribution, and duration. Start small: a low-intensity run confirms that your monitoring and your abort path work before you push volume.
• Simulate. Run the controlled test from the distributed fleet while watching live metrics: requests per second, success rate, and data transferred.
• Report. Export the result as an attested record of what happened.

Then you adapt. Tune a WAF rule, adjust a rate limit, raise a timeout, and retest to prove the fix worked. The retest is the part teams skip and the part that matters most. A fix you did not verify under load is a hypothesis, not a control.

What realistic traffic requires

A test is only as honest as the traffic behind it. Defenses that key on obvious signatures, such as a single source subnet, a fixed user-agent, or datacenter IP ranges, will “pass” a test that uses those same tells, then fail against a real botnet that does not.

Obsidio generates load from 100,000+ globally distributed real devices rather than virtualized instances, sourced from ethically sound providers. Traffic arrives from real hardware and smartphones across many networks and regions, so you are testing your defense against something that looks like a genuine distributed attack rather than a lab artifact your WAF can trivially filter.

Turning a test into compliance evidence

For a regulated institution, a passing test that leaves no record is worth little. The regulatory frameworks now expect the evidence, not just the effort.

Under the EU’s Digital Operational Resilience Act (DORA), financial entities must run a resilience testing programme with, at minimum, appropriate tests of the ICT systems supporting critical or important functions each year (Article 24). Significant entities must also undergo advanced threat-led penetration testing at least every three years (Article 26). NIS2 obliges essential and important entities to adopt risk-management measures and test them, and FINMA expects Swiss institutions to manage operational resilience on a comparable basis.

What these frameworks share is a demand for demonstrable, repeatable testing, the kind of assurance you can hand to an auditor or a board. Obsidio produces cryptographically attested, tamper-evident reports mapped to FINMA, DORA, and NIS2, generated inside Trusted Execution Environments so the result cannot be quietly edited after the fact. The output of a test becomes the artifact in your compliance file.

Strength is proven, not promised. A test you can attest to is what turns “we are resilient” into something an auditor can check.

Where to start

If you have never tested your DDoS protection, begin with a single authorized, low-intensity application-layer run against a staging environment or a scheduled window. Watch how your monitoring and mitigation respond, then widen the scope from there. The first test rarely produces a clean pass, and that is exactly why you run it before an attacker does.

To scope a controlled simulation against your own infrastructure, get in touch with the Obsidio team or request a demo. Independent, neutral, verifiable: resilience you can prove.