Protected URLs
Protecting sensitive URLs from attack helps prevent disruptive actions that can interfere with your assessment. Many sensitive URLs are identified and protected by XBOW automatically, and you can manually protect additional URLs to ensure safe testing.
Be aware that the breadth of your assessment is dictated by your scope boundaries, which define what domains are accessible and attackable. Protected URLs control the treatment of specific endpoints within those attackable domains. To learn more about assessment scope, see Scope configuration.
Automatically protected URLs (public preview)
To reduce interruptions in assessments, XBOW uses regular expressions to automatically identify and protect several types of disruptive URLs:
| URL category | Example endpoints | Why XBOW protects them |
|---|---|---|
| Authentication entry points |
| Attacks can trigger multi-factor authentication storms or account lockouts. |
| Destructive for accounts |
| Attacks can destroy the test agent’s account. |
| Destructive for sessions |
| Attacks can end the test agent’s session mid-assessment. |
| OAuth and multi-factor |
| Attacks can revoke tokens and toggle multi-factor authentication. |
| Password actions |
| Attacks can invalidate the test agent’s credentials. |
If you have an Enterprise account, you can see the endpoints XBOW automatically protected after your assessment completes. Protected endpoints are included in the “Coverage gap map” section of the assessment overview page, and are indicated by a blue “Skipped” icon.
Manually protected URLs
If your application has sensitive URLs that do not exactly match the example endpoints in the automatic protection table, you should manually protect them. You can protect URLs with the following designations:
- Auth-only: allow XBOW to contact but not attack authentication endpoints. If any URLs are pre-populated as “Auth-only”, they are necessary for authentication or session management, and their designation should not be changed.
- Blocked: stop XBOW from accessing the endpoints entirely.
In addition to the previously listed URL categories, consider protecting the following:
| URL category | Example endpoints | Recommended designation |
|---|---|---|
| High-risk production functionality |
| Blocked. You should identify and block high-risk endpoints to avoid unintended changes to your app. |
| Calls to out-of-scope systems |
| Blocked (optional). Unless your external systems are meant to be tested, you should block relevant URLs to maintain the appropriate assessment scope. |
Once an assessment starts, your protected URLs cannot be modified.
Troubleshooting manually protected URLs
Incomplete assessments
Symptom: Assessment completes quickly with limited findings or skips entire sections of the application.
Possible causes:
- URL rules are too broad and prevent legitimate testing
- Critical API endpoints are inadvertently blocked
- Pattern-based rules match unintended URLs
Solutions:
- Review rule patterns for overly broad matches
- Narrow rules to specific endpoints rather than entire paths
- Remove rules that prevent testing of intended functionality
Authentication failures during testing
Symptom: XBOW cannot maintain authenticated sessions during testing.
Possible causes:
- Session management endpoints are blocked
- Token refresh endpoints are blocked
- Authentication validation endpoints are blocked
Solutions:
- Ensure session management endpoints are set to “Auth-only” and not “Blocked”
- Allow access to token refresh and validation endpoints
- Review authentication flow to identify critical endpoints