Test and operate
Test only with permission
Keep active security testing inside an authorized scope and use local or intentionally vulnerable targets for destructive experiments.
Security tools send unusual and sometimes destructive traffic. Fuzzers, scanners, and enumeration probes can corrupt data, trigger real emails, or take a service down. Only test systems you own or have explicit, written permission to assess. This is a legal and ethical line, not a style preference.
Before running anything active, write the rules of engagement down.
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 reachedKeep destructive experiments local
Owning the application does not make every connected system disposable. Payload experiments belong on a disposable local lab, not on shared staging.
# Run an intentionally vulnerable target locally for payload work
docker run --rm -p 3000:3000 bkimminich/juice-shopA scanner points at staging, but staging shares a production email provider. A harmless account-enumeration test sends thousands of real messages. The blast radius reached a system that was never in scope, because the scope was defined by “the app I own” instead of every integration behind it.
Scope the targets, techniques, data, integrations, rate, contacts, and stop conditions explicitly. Rate-limit your tools and preserve the availability of shared environments, since other people depend on them. When you find a real issue, report it through the agreed contact rather than exploiting it further.
Write an authorization for one staging test and have the system owner confirm it. Run a bounded harmless probe, verify rate and stop conditions, then test that an excluded target is never contacted.
Lesson completed