Unlike Unauthenticated API Scans, which only target public endpoints, an authenticated scan allows ZeroThreat to interact with and test endpoints that require valid credentials or session tokens. This ensures your critical APIs are also covered in your security testing.
Before proceeding, it’s important to note that API Authentication is configured at the collection level. This means you’ll first need to create a Collection for your API target—where all your API definitions (endpoints) are managed. If your collection is already created, you’re ready to configure authentication and run your first authenticated API scan.
Inside the drawer:
ZeroThreat offers three API authentication methods:
Authentication Type | Purpose |
---|---|
Custom Headers | For static tokens, cookies or fixed header-based authentication. |
Configure Authentication Request Payload | For dynamic login flows where tokens are generated at runtime and may expire after certain time, making it essential to generate fresh login before each scan to ensure valid authentication (pair with Refresh Token if tokens are short-lived). |
Third-Party Login Request | For apps using an 3rd party API's (OAuth 2.0 and others). Configure the token endpoint, request body, and optional headers so ZeroThreat fetches an access token at scan start—no login endpoint from your API collection required (pair with Refresh Token if tokens are short-lived). |
If your API uses static tokens or keys:
For APIs that require a login flow:
Here, select:
Note: Skip the next step of Response Property Mapping if your Login API returns authentication token value in Response headers.
In some APIs, the authentication token (such as a Bearer token or session cookies) are returned inside the response body of the login API—rather than in the response headers. In these cases, ZeroThreat needs to know where exactly in the response body the token is located, so it can extract the value and automatically insert it as a header for all subsequent API requests during the scan.
You’ll do this by setting up a Response Property Mapping.
Example Scenario:
{
"data": {
"user": {
"token": "abc123xyz"
}
}
}
For this example:
Authorization
data.user.token
ZeroThreat will parse the JSON body, locate the token at the specified path, and add it to the Authorization
header for all future API requests in the scan.
This mapping step ensures ZeroThreat can successfully authenticate on each API call by dynamically attaching the correct token.
You can use this method of authentication when your application relies on an external identity provider (OAuth 2.0 or other 3rd party API's) to issue access tokens. Instead of picking a login endpoint from your API collection, you define the token request here. ZeroThreat will run this request before the scan, capture the access token, and attach it to all subsequent API calls.
POST
.https://zerothreat.example.com/oauth/token
).In the above example, ZeroThreat will take the value of data.user.token
and bind it to the value of Authorization
header with prefix for all subsequent API calls. This enables that an authenticated API scan with freshly generated token value is used for authenticated API scanning.
Some APIs issue short-lived access tokens (e.g., JWTs) and expect clients to refresh them before they expire. Use this when your token has a TTL: ZeroThreat will call your refresh endpoint on a schedule, use the existing token to obtain a new access token, and keep scanning without interruption. This pattern is common in OAuth 2.0 (“refresh_token” grant) and similar rotating-token schemes.
Note: This configuration is not mandatory, and it is only required if your API access tokens are short-lived (expire in short time).
Once your authentication setup is complete:
You can monitor the scan progress from the Scans section and review detailed results in your Scan Report once the scan finishes.
Next Step? Learn how to Interpret Scan Results and analyze vulnerabilities found in your API endpoints in Scan Report guide.