How do you keep a DAST scan inside its scope?

Define the scope as an explicit list of URL patterns, turn on any protected mode your scanner offers, and exclude logout, third-party and production hosts. Check the scope by reading the first crawl results before you let the scanner attack anything.

Why scope slips

A crawler follows links. A page on your test site links to a payment provider, a CDN, a partner portal, a help center on another domain. Left alone, the scanner may follow those links and start sending attack payloads to systems you do not own. That can breach the terms of those services and may be unlawful, so it is worth getting right. This is a practical safety point, not legal advice.

Definitions

• Scope: the set of URLs the scanner is allowed to attack.
• Context: in ZAP, a named grouping of a site's URLs, defined by regular expressions, that holds scope, authentication and session settings together.
• Protected mode: a scanner mode that blocks dangerous actions on anything outside scope.

What the ZAP docs say

The ZAP documentation on contexts says contexts are defined as a set of regular expressions applied to the URLs, and expects a context to correspond to a web application. Its documentation on modes describes a Protected mode in which you can only perform potentially dangerous actions on URLs in the scope, and recommends using it so you only attack sites you mean to. It also describes an Attack mode, where new in-scope nodes are actively scanned as soon as they are discovered. That is convenient on a test target and risky without a tight scope.

Steps

1. List what you own and may test. Hostnames, ports and paths for the test environment.
2. Write patterns, not guesses. Use the exact host, for example the staging name with a trailing path. A loose pattern like a bare domain can match more than you intend, including subdomains you did not mean to include.
3. Add exclusions. Logout, delete account, password reset and bulk email endpoints.
4. Turn on protected mode or the equivalent.
5. Run a crawl only. Review the discovered hosts. Anything that is not yours should be missing.
6. Review outbound references. Scripts and images from other hosts are fine to load but not to attack.
7. Start the attack phase once the list looks right.

A quick scope table

Keep the evidence

Save the scope list, the date and who approved it. If a partner later asks why their server saw odd traffic, you can answer from records.

Mistakes to avoid

• Using a regular expression that matches the whole domain when you meant one host.
• Forgetting the scanner may follow redirects to another host.
• Running an attack mode on a laptop pointed at the wrong environment.
• Not checking what the crawl found before attacking.

A worked example

A team owns a web store at a staging host, an API at a second staging host, and uses an external identity provider and a hosted payment page. They set up scope in a structured way.

They write two include patterns, one per staging host, each anchored so it cannot match a longer name. They add exclusions for the logout path, the account deletion path and the bulk invite path. They switch the scanner into its protected mode.

Then they run a crawl only. The discovered list contains a link to the marketing site and to the CDN. Neither is in scope, so the scanner records them but does not attack them. One surprise appears: a legacy admin path on the API host that nobody remembered. They add it to the scan plan with the owner's approval.

A pre-flight checklist

1. The scope list is written, dated and approved by the system owner.
2. Each pattern has been tested against a list of sample URLs, both ones that should match and ones that should not.
3. Redirects have been checked, since a login redirect may point to another host.
4. Destructive paths are excluded.
5. Protected mode, or the tool's equivalent, is on.
6. The scanner is configured to use only the test environment's credentials.
7. A crawl-only run has been reviewed.
8. The security operations team knows the source address and time window.

Testing your patterns

Regular expressions are easy to get slightly wrong. A pattern that omits an anchor at the end may match a similar host name that you do not own. A pattern that escapes the dot incorrectly may match an unexpected character. Test every pattern against a list of URLs you expect to match and a list you expect not to, before the scan.

What if the scanner leaves scope anyway?

Stop the scan, record what was sent and to whom, tell the owner of the system affected, and fix the scope. An honest note is better than silence. Then add the case to your pre-flight checklist so it does not happen again.

Third-party components on your pages

Your pages may load scripts from other hosts. The scanner will see those requests in a browser-driven crawl. Loading them is normal. Attacking them is not. Scope controls the second, not the first.

Where Safeguard fits

Scope control is about the web app you test. For the libraries inside it, 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.

Check which target the scan is aimed at before it starts testing.

Quick check

Sources

• ZAP: Contexts
• ZAP: Modes

Last reviewed: 19 October 2026.