Skip to main content

Credentials Configuration​

The Credentials section defines how the scanner authenticates to access protected areas of the application during a scan.

Credentials are required when performing scans that need access to authenticated functionality, such as:

  • user dashboards
  • internal APIs
  • admin panels
  • protected business workflows

This allows the scanner to analyze vulnerabilities that exist only after authentication, such as authorization issues, broken access control, and business logic flaws.

Credentials are configured after selecting a scanner in the scan creation workflow.

When Credentials Are Required

Credentials appear only when a scanner that supports authenticated testing is selected.

Authenticated Web Application Scan​

When the following scanner is selected:

Authenticated (Credentialed) Scan

This scanner performs in-depth security testing using provided credentials to identify:

  • OWASP Top 10 vulnerabilities
  • business-logic vulnerabilities
  • authorization issues across roles
  • vulnerabilities in protected APIs and application areas

After selecting this scanner, the next step allows you to configure Authentication Mode and credentials.

Authentication Modes

Two authentication modes are supported for authenticated scanning.

1. Username & Password Authentication​

This mode logs into the application using user credentials during the scan.

The scanner performs the login automatically using the authentication configuration defined in the scan settings.

Required Fields​

FieldDescription
UsernameUsername used for login
PasswordPassword used for login

Optional Field​

FieldDescription
RoleOptional label describing the user role

The Role field is useful for organizing scans and identifying the type of access used during testing.

Common role examples include:

  • admin
  • test-user
  • readonly
  • analyst
  • developer

Example configuration concept:

Username: admin@example.com Password: ******** Role: admin

This allows the scanner to authenticate and explore protected areas available to that user role.

2. Inject Cookie / Token​

This mode allows the scanner to reuse an already authenticated session instead of performing login.

A session cookie or API token is injected into requests so the scanner can access protected endpoints automatically.

This is useful when:

  • authentication flows are complex
  • SSO is used
  • MFA is enabled
  • authentication cannot easily be automated

Required Field​

FieldDescription
Cookie / TokenExisting session cookie or API token

Optional Field​

FieldDescription
RoleOptional role associated with the session

Example session cookie:

Cookie: SESSIONID=abc123xyz

Example token:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

The scanner will include this value in all requests to access authenticated content.

Special Note: Direct Header Injection​

Instead of using the Cookie / Token field in the frontend, you can directly inject authentication headers via the automation YAML (headers: section).

This is especially useful when you want to skip the credentials UI and provide:

  • Authorization tokens (Bearer, JWT, etc.)
  • Session cookies
  • Optional business headers like Role, Version, Tenant-ID

Example:

headers:
  Type: "admin"
  Version: 1.21.5
  Authorization: "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

If headers are injected directly, the Inject Cookie / Token UI fields can be left empty. The scanner will automatically use the headers in all requests, and optionally use a pollUrl for verification.

Credentials for API Testing

Credentials are also configurable when using the following scanners.

OWASP ZAP Web & API Scanner​

This scanner performs automated vulnerability testing against:

  • web applications
  • REST APIs
  • backend services

Authentication can be configured using:

  • Bearer Token
  • Session Cookie

Optional fields include:

  • Role
  • Custom Headers

Example:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... Role: admin X-Client-ID: web

OpenAPI Spec Testing​

This scanner verifies API functionality, performance, and security based on an OpenAPI specification.

Currently supported authentication methods include:

  • Bearer Token
  • Cookie-based authentication

Optional fields:

  • Role
  • Custom headers

Example configuration:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... X-Client-ID: web

These values will be included in API requests during testing.

Optional Role Field

The Role field is optional but recommended when scanning applications with multiple permission levels.

Examples:

RoleTypical Access
adminFull system access
userStandard application access
readonlyView-only permissions
test-userQA or staging user

This helps track which user context was used during the scan and improves vulnerability reporting.

Custom Headers

Some applications require additional headers for authenticated requests.

These may include:

  • tenant identifiers
  • client identifiers
  • application version headers
  • organization identifiers

Example:

X-Client-ID: web X-Tenant-ID: tenant-1 Version: 1.1.0

Custom headers can be included along with cookies or tokens when performing authenticated API testing.

Using ZAP Automation Files

Credentials may not be required if authentication is already defined in a ZAP Automation File.

When a ZAP Automation Plan is uploaded instead of using the DeepTraq YAML configuration:

  • username
  • password
  • injected cookies

can be omitted.

In this scenario, authentication is handled directly by the automation plan.

Summary

Credentials are configured after selecting a scanner that supports authenticated testing.

ScannerSupported Authentication
Authenticated (Credentialed) ScanUsername & Password, Inject Cookie/Token
OWASP ZAP Web & API ScannerBearer Token, Cookie
OpenAPI Spec TestingBearer Token, Cookie

Providing valid credentials allows the scanner to test protected application areas and APIs, enabling deeper security analysis beyond publicly accessible endpoints.