The short answer
Only test systems you own or are explicitly authorized in writing to test, and obtain any required approval from the operators of infrastructure that carries, hosts, fronts, or protects the target.
A DDoS simulation is controlled load generation with a defensive purpose: measuring capacity, validating protections, and rehearsing incident response. It is not automatically lawful simply because it is called a “test.” Its legal basis depends on authorization, a clearly bounded scope, compliance with provider terms, and the laws that apply to the parties and infrastructure involved.
This page provides general information, not legal advice. Organizations should obtain their own legal advice where the scope, jurisdiction, or potential impact is uncertain.
Who must approve the test?
Approval should come from an authorized representative of the organization that owns the target and from every separate operator whose systems may be directly tested or materially affected. Depending on the architecture, that can include:
- the business or organization that owns the application or service;
- the team that operates the target servers, network, and security controls;
- the hosting or cloud provider, when its policy requires advance permission or notice;
- the CDN, reverse-proxy, load-balancing, or DDoS-mitigation provider in front of the target;
- a managed-service provider or other third party responsible for affected infrastructure; and
- ddos-sim.com as the testing provider, through an accepted plan and signed Rules of Engagement.
The person giving approval must have authority to do so for that organization. Consent from a developer or domain administrator does not necessarily authorize a disruptive production test on infrastructure owned or operated by someone else.
What written approval should cover
A useful authorization is specific enough that everyone can tell what is permitted and what is not. The Rules of Engagement should record:
- the legal entities approving and performing the test;
- the exact domains, addresses, services, and environments in scope;
- systems and shared infrastructure that are explicitly out of scope;
- the techniques, traffic rates, concurrency, worker count, and maximum duration;
- the approved date, time window, and time zone;
- the expected impact, accepted risks, health thresholds, and stop conditions;
- named operational and emergency contacts with authority to stop the test; and
- any provider notifications, approvals, change records, or regulatory conditions.
If the target, timing, technique, or intensity changes, the authorization should be reviewed again. Permission for a small HTTP load test does not automatically cover a network-layer flood or a different production environment.
Domain verification is not permission
Proving control of a domain is an important technical safeguard, but it answers only one question: can the customer make an approved change or response on that domain? It does not prove that the customer owns every server, network, CDN, or mitigation platform behind it, nor that every operator has agreed to receive simulated attack traffic.
ddos-sim.com therefore treats domain verification and legal authorization as separate requirements. Both matter, and neither replaces the other.
How ddos-sim.com keeps approval tied to the test
Each engagement is reviewed as a specific plan. Before it can run, the target must be verified, the plan must be accepted and priced, and an authorized representative must sign the Rules of Engagement for that plan revision. Changing the target, timeline, techniques, rates, concurrency, workers, or safety controls requires renewed review and approval.
Technical controls keep execution within that approved scope: each worker is assigned one verified domain, private and loopback destinations are blocked, public addresses are pinned, and rate, concurrency, duration, and worker counts are bounded. Live health thresholds can stop the test automatically, and the customer can stop it manually.
These controls support a lawful, documented engagement; they do not create permission where permission has not been obtained. The customer remains responsible for securing all approvals required by law, contract, and provider policy.
When not to test
Do not proceed if any affected party has not approved, if the approver's authority is unclear, if a provider prohibits the planned technique, or if the test could spill into shared or safety-critical systems. Pause and re-scope whenever the actual architecture or likely impact differs from what was approved.
For the binding conditions that apply to ddos-sim.com engagements, read the authorization requirements in our Terms of Service and our Acceptable Use Policy.