Allow configurable availability check for API Fuzzing Analyzer & DAST API Analyzer base/target URL
Summary
Currently when using the API Fuzzing Analyzer or DAST API Analyzer, the target API base URL that is configured via FUZZAPI_TARGET_URL
for the API Fuzzing Analyzer or the DAST_API_TARGET_URL
for the DAST API Analyzer, appear to be subject to an availability check, wherein the analyzer will not actually start, depending on the status code that is returned when hitting the base URL.
This is problematic in cases where the base URL itself does not have any exposed API endpoint or is not responsive, compared to the actual endpoint paths that do expose API endpoints intended for analysis.
For example, if the relevant API endpoints to be scanned are at api.example-base-url.com/api/v4/*
, before the analyzer will start, it performs a check against api.example-base-url.com
- and depending on the status code returned, the job may fail before the analyzer has a chance to really start.
What is the current behavior?
If the base URL returns a status such as 500
, then the API Fuzzing Analyzer or DAST API Analyzer job will fail before any scanning really starts. The job log will look similar to this:
[INF] API Fuzzing: Waiting for scan target (https://api.example-base-url.com) to become available...
[INF] API Fuzzing: Backing off 0.4 seconds afters 1 tries
[INF] API Fuzzing: Backing off 1.3 seconds afters 2 tries
[INF] API Fuzzing: Backing off 0.5 seconds afters 3 tries
[INF] API Fuzzing: Backing off 5.0 seconds afters 4 tries
[INF] API Fuzzing: Backing off 14.3 seconds afters 5 tries
[INF] API Fuzzing: Backing off 9.0 seconds afters 6 tries
[INF] API Fuzzing: Backing off 62.5 seconds afters 7 tries
[INF] API Fuzzing: Backing off 33.8 seconds afters 8 tries
[INF] API Fuzzing: Backing off 22.7 seconds afters 9 tries
[INF] API Fuzzing: Backing off 149.1 seconds afters 10 tries
[WAR] API Fuzzing: Waiting for url 'https://api.example-base-url.com', failed: Error status code received: 500
[ERR] API Fuzzing: Error waiting for target 'https://api.example-base-url.com' to become available.
Stopping scanner...
[INF] DAST API: Waiting for scan target (https://api.example-base-url.com) to become available...
[INF] DAST API: Backing off 0.4 seconds afters 1 tries
[INF] DAST API: Backing off 1.3 seconds afters 2 tries
[INF] DAST API: Backing off 0.5 seconds afters 3 tries
[INF] DAST API: Backing off 5.0 seconds afters 4 tries
[INF] DAST API: Backing off 14.3 seconds afters 5 tries
[INF] DAST API: Backing off 9.0 seconds afters 6 tries
[INF] DAST API: Backing off 62.5 seconds afters 7 tries
[INF] DAST API: Backing off 33.8 seconds afters 8 tries
[INF] DAST API: Backing off 22.7 seconds afters 9 tries
[INF] DAST API: Backing off 149.1 seconds afters 10 tries
[WAR] DAST API: Waiting for url 'https://api.example-base-url.com', failed: Error status code received: 500
[ERR] DAST API: Error waiting for target 'https://api.example-base-url.com' to become available.
Stopping scanner...
A status code response of 200
or 403
for example, will seem to allow the job to continue past this point.
What is the desired behavior?
The desired behavior would be if this initial availability check can be configured in some way such as for example:
- Toggle on/off entirely
- Specify which status response codes can be ignored
- Specify an exact URL specifically for the availability check
Implementation Plan
-
Add new variable APISEC_TARGET_CHECK_DISABLED
-
Add new variable APISEC_TARGET_CHECK_STATUS_CODE
-
Document new variables