Scope configuration
XBOW enforces domain scope boundaries at the network level during assessments. Proper scope configuration ensures comprehensive testing while protecting out-of-scope systems.
Important: Incorrect scope is a common cause of failed or incomplete assessments and wasted attack credits. If a domain the target needs is not defined as “Attackable” or “Allow Visit”, XBOW treats it as blocked. This can prevent XBOW from loading the target, maintaining an authenticated session, or reaching parts of it, so the assessment ends early with limited findings. Review the proposed scope carefully before you start. See Troubleshooting scope issues.
Domain scope rules
After the configuration check phase, XBOW proposes initial scope rules based on domains accessed during authentication and discovery. Review these rules to ensure all target components are included but only the planned domains are attacked.
The target domain is marked Attackable. Other domains XBOW discovers, including subdomains of your target and third-party sites, are marked Allow Visit. To test subdomains, add a wildcard rule such as *.example.com in the “Scope” area.
Domain rule types
- Attackable: Actively tested for vulnerabilities. Use this only for domains that are part of the core functionality. For example:
- Primary domain, such as
www.example.com - API endpoints, such as
api.example.comorgraphql.example.com - Internal services, such as
internal.example.com - AI or specialized services, such as
llm.example.com
- Primary domain, such as
- Allow Visit: Visit but do not test. Use this for domains that support functionality but should not be tested. For example:
- Content delivery networks (CDNs)
- Analytics or telemetry services
- External domains serving resources required for rendering, such as JavaScript files, fonts, and images
- Third-party authentication providers
- SSO services
- Blocked: Do not access or test. Use this only for domains that should never be accessed. Any domain not explicitly listed in the scope is treated as blocked.
Tip: Domain rules control scope at the hostname level. To restrict testing to a subpath or specific ports, see Restrict scope with regex patterns.
Exclusion rules
Use exclusion rules to keep XBOW away from parts of your asset. The rule you choose determines how firmly XBOW avoids the excluded area.
| Rule | What it excludes | Where to set it | How it works |
|---|---|---|---|
| Blocked domain | An entire domain | “Scope” section of the “Configuration check” page | XBOW does not access this domain. XBOW never attacks a domain that is not in scope. |
| Allow Visit domain | Attacks on a domain | “Scope” section of the “Configuration check” page | XBOW visits the domain but does not attack it. |
| Blocked URL | A URL, subpath, or port, including patterns that match many URLs | Manually protected URLs and Restrict scope with regex patterns | XBOW does not access the matching URLs. |
| Auth-only URL | Attacks on an authentication URL | Manually protected URLs | XBOW contacts the URL, for example to sign in, but does not attack it. XBOW sets this automatically for authentication URLs it finds during the configuration check. |
| Priorities exclusion list | Features or endpoints that should receive less attention | “Priorities” card, see Provide asset context | Not enforced. XBOW deprioritizes the excluded areas but cannot guarantee that it never touches them. |
If something must never be tested, block the domain or the URL. XBOW enforces these rules. For more information, see Exclude part of your asset from testing.
Troubleshooting scope issues
Most scoping problems are the result of blocking a domain that the attackable domains need access to for functionality that’s being tested. This manifests in different ways according to the purpose of the blocked domain.
Incomplete assessments
Symptom: Assessment completes quickly with limited findings or authentication failures occur during testing.
Possible causes:
- Critical domains are blocked or missing from scope
- JavaScript resources required for logic are blocked
- Authentication-related domains are not accessible
Solutions:
- Add missing domains to scope as “Attackable” or “Allow Visit”. To ensure XBOW can visit relevant subdomains that are not already in scope, you can use a wildcard (for example,
*.example.com). - Review authentication flows to identify required domains
- Configure authentication providers as “Allow Visit” rather than “Blocked”
Application rendering issues
Symptom: XBOW reports difficulty identifying UI elements or navigating the target.
Possible causes:
- Static resources (images, fonts, stylesheets) are blocked
- CDN domains are not accessible
- Required JavaScript files cannot load
Solutions:
- Configure CDN domains as “Allow Visit”
- Ensure domains that host static resources are accessible
- Review browser console errors to identify blocked resources
Failed authentication
Symptom: XBOW cannot maintain authenticated sessions during testing.
Possible causes:
- Authentication-related domains are blocked
- Your authentication header is not sent to the necessary endpoints
- Session management services are not accessible
- Token refresh endpoints are out of scope
Solutions:
- Configure authentication providers as “Allow Visit”
- Include your authentication header in requests to all hosts in assessment scope
- Add session management domains to scope
- Ensure token refresh endpoints are accessible