Test only with permission

Security tools send strange, and sometimes destructive, traffic. A fuzzer can corrupt data. A scanner can trigger thousands of real emails. So the rule comes before the tooling: only test systems you own or have explicit, written permission to test. This is a legal line, not a style preference. In most countries crossing it is a crime even when you meant well.

Write the rules of engagement first

Before you run anything active, write down what’s allowed. Keep it short enough to read in a minute:

Target:        staging.flaviocopes.com only
Window:        2026-08-10 02:00–04:00 UTC
Allowed:       read probes, auth checks, rate ≤ 5 req/s
Excluded:      production email provider, real customer records
Contact:       [email protected]
Stop when:     any 5xx spike or an excluded system is reached

Every line answers a question you’d otherwise face under pressure. Which host? When? How hard? What’s off limits? Who do I call? When do I stop? Get the system owner to reply “agreed” to that text, and keep the reply.

Notice the rate limit. Most scanners default to hundreds of requests per second. Set yours to the agreed number before you start, and check it. With ffuf that’s -rate 5. With a script, a sleep 0.2 between requests does the job.

Keep destructive experiments local

Owning the application doesn’t make every connected system disposable. Staging talks to real third parties. Payload experiments belong in a lab you can throw away.

The easiest lab is an intentionally vulnerable app in a container:

# Run an intentionally vulnerable target locally for payload work
docker run --rm -p 3000:3000 bkimminich/juice-shop

Open http://localhost:3000 and you have OWASP Juice Shop, a deliberately broken store with dozens of real vulnerabilities. Break it as hard as you like. When you’re done, Ctrl+C removes the container and nothing outside your laptop noticed.

The blast radius nobody drew

Here is the failure that makes this lesson necessary. A team points a scanner at staging. Staging is theirs, so it feels safe. But staging uses the same transactional email provider as production. The scanner’s account-enumeration test hits the “forgot password” form a few thousand times, and a few thousand real emails go out to real addresses on the provider’s shared reputation. The provider suspends the account. Production can’t send email.

The scope said “the app I own”. It should have said “the app, and every integration behind it”. That’s what the Excluded line in the rules is for.

When you do find a real issue, stop there. Report it through the agreed contact with the exact request that reproduces it. Don’t pull more data to prove the point. One record is proof. A thousand is a breach.

Try this on your own project: write the rules of engagement for one staging test and get the owner’s confirmation in writing. Run a bounded, harmless probe at the agreed rate. Then check your tool’s logs and confirm the excluded system was never contacted.