Guiding XBOW testing for experts
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 asset or a specific assessment.
Tip: All users can provide source code and documentation to give XBOW information about their asset. 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
You 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 | Validates canary tokens you supply. |
| General guidance and Safety guidance | Extracted automatically from input to the other cards | General guidance is applied to every attack agent. Attack agents receive safety guidance as constraints, and the safety-checker agent uses it to evaluate actions. |
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.
Note: The Limit testing to the listed endpoints toggle removes everything you do not list, including the login and session endpoints XBOW would otherwise discover. Ensure that you include those endpoints explicitly, or XBOW will not be able to authenticate. To keep them reachable without attacking them, mark them Auth-only in Protected URLs.
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 methods and endpoint-specific preconditions. XBOW uses these to select and configure the attacks it runs.
The primary types of input are:
- Per-attack hints: A plain-text description of how XBOW should approach a specific attack method on your asset. For example, if you know the asset 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.
Attack methods
Each comprehensive assessment runs the generally available attack methods. To add methods that are still in preview, turn on the Public preview or Private preview stage. For more information, see Choose preview stages.
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.
Canary tokens are required if you select Custom canaries under “Additional testing”.
For setup instructions, see Validate results with canary tokens.
General and safety guidance
When you click Analyze on a card, XBOW also extracts two cross-cutting categories from your input:
- General guidance: Information relevant throughout testing, not tied to a specific endpoint or attack method. For example: test IDs and values, parameters to add to all queries, headers required in certain cases, or quirks of the target.
- Safety guidance: Actions to avoid or treat with caution, and explicit instructions against specific behaviors.
The card displays any guidance it extracts from your input. When you save a card with guidance, you will also see an aggregated view below the four cards showing the combined guidance across all cards.
XBOW uses these items differently from the card-specific outputs:
- General guidance items are added to the beginning of the system prompt for every attack agent, so they apply across the whole assessment.
- Safety guidance items are given to attack agents as constraints, and the safety-checker agent uses them to evaluate whether a planned action should proceed. For advice on writing them, see Write effective safety guidance.
Tip: If these lists are shown, review them carefully before starting the assessment. This is particularly important for the safety guidance list. The safety extractor errs on the side of caution and can unnecessarily restrict attacks. Delete any items that should not constrain testing.