Guiding XBOW testing for experts
- Enterprise only
- Public preview
By default, XBOW performs undirected testing: it discovers endpoints, chooses which attacks to run, and allocates effort based on its own heuristics. This works well for general coverage but may not reflect what matters most for a specific application or a specific assessment.
Tip: All users can provide source code and documentation to give XBOW information about their application. The uploaded information is used by the whole assessment process to give more efficient testing with more accurate and relevant findings. For details, see Guiding XBOW testing.
Uploads to guide specific test processes
Enterprise users can use additional options to give XBOW information that informs specific areas of the test process. This is more like briefing a human pentester, explaining which endpoints to attack, what attacks to prioritize, and how to validate results.
| Card | What to Add | Impact |
|---|---|---|
| Attack surface | API specs, documentation, endpoint lists | Uploaded endpoints are always attacked. Details of how to interact with endpoints are used. Can block the discovery of other endpoints. |
| Priorities | Feature areas to focus on or avoid, potentially vulnerable features | Assessment is directed by your preferences |
| Attack strategy | Known vulnerability patterns, payloads, attack strategies | Attack agents use the vulnerabilities, payloads, and strategies |
| Validation | Add canary tokens | Validators canary tokens you supply. |
Attack surface
Use when you have API specs available, when your API surface is large, or when scope agreements require you to restrict testing to known endpoints.
You provide API specifications or technical documentation describing your endpoints. XBOW extracts a structured list of endpoints — each with its path, HTTP method, access method, and authentication requirements — and adds them to the attack surface it will test.
By default, your provided endpoints are included but XBOW will also run discovery agents to search for additional endpoints to attack. Use the optional “Limit testing to the listed endpoints” toggle to test only the endpoints you provided and block automated discovery.
Priorities
Use when you have areas that are out of scope, under active maintenance, already covered by other tooling, or where you want to concentrate effort on high-risk components.
You describe which features or endpoints should receive more or less testing attention. XBOW produces two lists from your input: things to focus on, and things to exclude.
Tip: The exclusion list is applied on a best-effort basis. XBOW deprioritises those areas but cannot guarantee they will never be touched if they are reached as part of another test path. If you need to block access to URLs entirely, see Controlling access to sensitive endpoints.
Attack strategy
You provide hints about attack types and endpoint-specific preconditions. XBOW uses these to select and configure the attacks it runs.
The primary types of input are:
- Per-attack-type hints: A plain-text description of how XBOW should approach a specific attack type on your application. For example, if you know the application is particularly exposed to SQL injection in a specific way, you can describe it here.
- Endpoint-specific preconditions: Context about what needs to be true before attacking a specific endpoint — for example, authentication state, required parameters, or setup steps.
Disable some types of attack
By default, each assessment attacks the target application with all available types of attack. You can disable some types of attack to focus on finding exploitable vulnerabilities in the remaining types of attack. For example, if you have recently fixed a cross-site scripting (XSS) vulnerability in the application, you might run an assessment just checking for additional XSS vulnerabilities.
Validation
You can define canary tokens.
Using canary tokens
Canary tokens are especially useful when you:
- Search for flaws in business logic because the canary gives attack agents a concrete target instead of ambiguous behavior.
- Need definitive proof for SQL injection, file read, or remote code execution. These can be demonstrated without using canary tokens, but canaries make validation stronger and reduce false positive results.
For setup instructions, see Validate results with canary tokens.