Treat an active DAST scan as a very enthusiastic user with bad intentions. Point it at disposable data, exclude destructive endpoints, block outbound email, and reset the environment after every run. Never aim it at data you cannot rebuild, and never at a shared environment other teams rely on.
What can go wrong
An active scan submits every form it finds with hundreds of variations. That can create thousands of junk records, fill queues, trigger emails to real addresses, lock test accounts through repeated failed logins, and call delete or reset endpoints. The ZAP documentation notes that active scanning performs actual attacks, which is why it should only run against targets you own and are ready to rebuild.
Prepare the environment
| Risk | Control |
|---|---|
| Junk records | Run on a copy of the database or a fresh seed |
| Emails and messages to real people | Route mail to a sink, disable SMS and push sending |
| Payments | Use a sandbox payment mode with no live keys |
| Account lockouts | Use dedicated scan accounts and a reset step |
| File uploads | Send to a temporary store and clean up |
| Third-party calls | Stub or block them in the test environment |
| Delete and reset endpoints | Exclude them from the scan scope |
Steps
- Use a dedicated environment. Not shared staging that others rely on.
- Seed fake data. Synthetic records only. Keep real customer data out.
- Exclude destructive paths. Account deletion, password reset, bulk operations, data export and admin purge actions.
- Neutralize side effects. Send mail to a catch-all sink and use payment sandboxes.
- Create scan-only accounts and rotate or delete them after the run.
- Snapshot first. Take a database snapshot or use a container with a known state.
- Run the scan with a time cap and monitor storage and queue depth.
- Reset afterward. Restore the snapshot and confirm the environment is clean.
- Record what changed. If anything leaked outside the sandbox, note it and fix the cause.
Test the exclusion list
An exclusion is only useful if it matches. After you set the list, run a short crawl and check the discovered paths for anything destructive. Regular expressions that are too narrow let delete links through, and ones that are too wide skip areas you want tested.
What about production?
Passive checks only. If you must test production, agree the scope in writing with the service owner, run at a quiet time, use a dedicated account, and exclude every state-changing endpoint. Many teams simply decide production is off limits for active scans.
Common mistakes
- Using a copy of production with real personal data.
- Forgetting that an email service in staging may use real SMTP credentials.
- Leaving scan accounts active after the run.
- Not resetting between runs, so each scan starts from a messier state.
A worked example
A team runs its first active scan on a shared staging environment on a Friday evening. On Monday the support team reports 9,000 new "test" tickets, 300 password reset emails sent to a shared mailbox, a payment sandbox that ran out of quota, and three test accounts locked. The cleanup takes two days. The numbers are an invented illustration, but each effect is a common one.
The team then rebuilds the process.
| Problem | Fix |
|---|---|
| Junk tickets | Scan on a disposable copy, not the shared environment |
| Password reset emails | Mail sink for the whole environment, checked with a test message |
| Payment sandbox quota | Stub the payment call during scans |
| Locked accounts | Dedicated scan accounts, reset in the cleanup job |
| Slow cleanup | Database snapshot restored in minutes |
| Surprise for the support team | Notice sent before every run |
A run plan template
- Before. Restore the snapshot. Create scan accounts. Verify the mail sink with a test message. Confirm the scope file and exclusions. Notify support and operations.
- During. Watch storage, queue depth and error rates. Keep a named person on call who can pause the scan.
- After. Collect the report and the records. Restore the snapshot. Delete scan accounts. Confirm that nothing was sent outside the sandbox.
- Review. Note any side effects, add exclusions or stubs, and update the plan.
Destructive endpoints worth excluding
| Endpoint type | Why |
|---|---|
| Account deletion | Removes the scan account mid-run |
| Password and email change | Locks the account out of the scan |
| Bulk delete or purge | Removes seed data |
| Data export | Produces large files |
| Invite and share by email | Sends messages |
| Admin reset tools | Changes shared state |
Exclude them from the scan, then test them by hand with care, because they still deserve security review.
Files and storage
Upload forms are a special concern. A scanner may upload hundreds of files with odd names and types. Direct uploads to a temporary store and clear it afterward. Check that file size limits are in place so the scan does not fill a disk.
Data protection angle
If staging contains copies of real customer data, a scan may also expose that data in reports and logs. Replace production data with synthetic data before scanning, and keep stored requests from the scan under access control. If you work under privacy rules, check with your privacy lead, since this post is not legal advice.
Make the safe path the easy path
Wrap the whole routine in a single script or pipeline job: restore, seed, scan, collect, reset. If safe scanning takes one command, people will use it. If it takes twelve manual steps, someone will skip three.
Where Safeguard fits
Protecting test data is a web testing discipline. For the software dependencies behind the app, Safeguard offers SBOM and dependency scanning with reachability analysis, and a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice the scan target and think about which of its actions would change data.
Quick check
Is a copy of production safe to scan?
Only if personal data is removed or replaced. Prefer synthetic seed data.
How do I stop emails going to real users?
Route all outbound mail to a sink in the test environment and verify with a test message first.
How can I check that the environment really reset?
Compare record counts, queue lengths and account states with the snapshot baseline, and send a test message to confirm the mail sink still works.
Sources
Last reviewed: 19 October 2026.
