Protected URLs
Protecting sensitive URLs from attack helps prevent disruptive actions that can interfere with your assessment. This reduces the chance that your assessment will be paused because the test account cannot authenticate or is damaged.
XBOW has two levels of protection:
- Scope: Controls which domains are accessible and which can be attacked. See Scope configuration.
- Protected URLs: Control which endpoints within accessible domains can be used for authentication, and which can be attacked.
Many sensitive URLs are identified and protected by XBOW automatically, and you can manually protect additional URLs to ensure safe testing.
Automatically protected URLs (public preview)
XBOW automatically protects endpoints where an attack is likely to disrupt assessments. This includes endpoints that are needed to authenticate and maintain sessions with the asset, and endpoints that might disable the primary test account.
Lock discovered endpoints
When you save your target configuration, XBOW checks that the credentials defined are valid and the site can be accessed.
Any endpoints used to authenticate or maintain sessions during configuration checks are locked with the “Auth-only” setting, allowing access during the assessment but blocking attacks. You will see a blue button reporting the number of URLs that are locked. Click the button to see the detailed list.
Protecting these endpoints is important because attacking them pauses the assessment, which can only resume when you reset the test site.
Warn about sensitive endpoints
To further reduce interruptions in assessments, XBOW uses regular expressions to automatically identify and protect several additional types of disruptive URLs. If you block a URL that might make it difficult to assess your application, a warning is shown. We recommend that you set any endpoints that trigger a warning to “Auth-only” instead of “Blocked”.
Examples of sensitive endpoints
| 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. |
In addition to the examples in this table, regular expressions protect other URLs that link destructive terms with 2fa, account, email, mfa, otp, password, session and totp. Terms linked with hyphens or with underscore symbols are protected.
Tip: 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