Skip to main content
Every project has a client and a scope. The scope guard checks every host, name and URL against your rules before any tool touches it, and out of scope always wins. Anything seen outside scope is logged, never probed.
The Out of scope page keeps a clean record of what was excluded

The Out of scope page keeps a clean record of what was excluded

​
Scope rule types

A path can end with * for an explicit prefix match (/api* matches /api, /api-v2, /api/x).

​
Path-limited hosts

A rule with a path or port is limited: the host is reachable for the web stages (its in-scope URLs are probed, crawled and screenshotted) but is never port scanned, and nothing outside the allowed path is ever requested. A crawler is constrained to the allowed URL patterns. This lets you test one application on a shared host without touching the rest.

​
How recon enforces it

  • Brute-force and permutation candidates under excluded names are never resolved.
  • Excluded IPs are subtracted from ranges before a mass port sweep.
  • A discovered name is followed from an IP only when every address it resolves to is an in-scope IP.
  • Wordlists are trimmed so excluded paths are never requested, and no tool follows a redirect out of scope.
  • An out-of-scope rule with a path removes only the URLs under that path.

​
Out of scope

Names, IPs and URLs that turn up outside scope land on the Out of scope page: seen, never probed. For each you can add it to scope (the next run includes it), log it as an observation for the client, or ignore it. Logged observations can be included in the report.
Run d0pam1ne project check <target> to test whether a target is in scope before a run; it exits non-zero if the target is refused, and d0pam1ne scope plan explains what recon will do for each rule.