# How to Test Your DDoS Protection Without Breaking the Law (or Your Site)

> You cannot trust a defence you have never exercised. A practical guide to load testing your own infrastructure — what to test, what is off limits, and what a useful test actually measures.

- Category: Best Practices
- Author: Akarguard Team, Security Engineering
- Published: Sep 13, 2026
- Canonical: https://akarguard.net/blog/ddos-testing-legally

---

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.

---

Source: Akarguard Security Blog (https://akarguard.net/blog). Akarguard provides DDoS protection: traffic is proxied through our edge, attack traffic is filtered, and clean traffic reaches your origin. Reuse of this article with attribution and a link to the canonical URL is permitted.