Protection that has never been tested is a belief, not a control. But testing DDoS defences sits close to a line that carries real legal consequences, and the difference between a professional exercise and a criminal offence is mostly paperwork and scope.
The Rules
- Only test infrastructure you own or have written permission to test. Written, specific, and current — a verbal agreement is not a defence.
- Tell your hosting provider and your protection provider beforehand. Unannounced load looks exactly like an attack, because it is one.
- Never use a stresser or booter service. Paying one is, in most jurisdictions, the same offence as attacking someone with it, and you are also funding the ecosystem that attacks your customers.
- Stay inside your own network boundary. Testing that traverses a third party network without consent involves systems you were not authorised to affect.
The scope document
Write down what you will test, from where, at what intensity, during which window, and who can call it off. If something goes wrong, that page is the difference between an incident review and an investigation.
What Is Worth Testing
The interesting failures are rarely about raw volume. They are about what breaks when the edge changes behaviour: does the payment provider callback survive a challenge page, does the mobile app handle a 429, does the health check get rate limited, does the monitoring system alert before a customer does.
- Application load: realistic request mixes against expensive endpoints, ramping until something degrades. The goal is to find the knee, not to break the machine.
- Challenge behaviour: put the edge into its strictest mode during a quiet hour and use the site as a customer, on a phone, on a slow connection.
- Integration resilience: run your API clients, webhooks, and third party callbacks while protection is active.
- Recovery: how quickly does everything return to normal after you turn the load off?
Measure the Right Things
A test that reports a maximum requests per second number tells you almost nothing useful. Record time to detection, time to mitigation, error rate at the origin during the event, whether real user journeys still completed, and which alert fired first. Those are the numbers you will wish you had during a real incident.
Afterwards
Write the results down the same day, including the things that surprised you. A test that finds nothing is either an unusually healthy system or, far more often, a test that was too gentle to be informative.