Skip to main content

The token contained in this response can be referenced using the placeholder syntax:

{%json:fieldName%}

The scanner will:

  1. Parse the login response body
  2. Extract the value of the specified JSON field
  3. Insert that value into the Authorization header for all requests

Identifying the Token Field​

To determine the correct field name:

  1. Open your browser
  2. Login normally to the application
  3. Open Developer Tools → Network tab
  4. Locate the login request
  5. Inspect the Response Body

Look for fields that contain a token or JWT value.

Example login response:

{
  "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

In this case the token field is accessToken.

Configuration example:

Authorization: "Bearer {%json:accessToken%}"

Authorization Header Formats​

Different applications format the Authorization header differently. You must match the exact format used by the application.

Format 1 — Bearer Token (Most Common)​

Most APIs use the Bearer token format.

Example authenticated request header:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Configuration:

Authorization: "Bearer {%json:accessToken%}"

Format 2 — Token Without Bearer Prefix​

Some applications send the token directly without the Bearer prefix.

Example request header:

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Configuration:

Authorization: "{%json:accessToken%}"

Adding the Bearer prefix when the server does not expect it will cause authentication failures.

Common Token Extraction Examples​

Example 1 — Token Stored as token​

Login response:

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

Configuration:

Authorization: "Bearer {%json:token%}"

Example 2 — Token Stored as accessToken​

Login response:

{
  "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

Configuration:

Authorization: "Bearer {%json:accessToken%}"

Example 3 — Token Nested in JSON Object​

Login response:

{
  "data": {
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
  }
}

Configuration:

Authorization: "Bearer {%json:data.token%}"

Nested JSON fields can be accessed using dot notation.

Example 4 — Token Returned in Authorization Field​

Login response:

{
  "Authorization": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

Configuration:

Authorization: "Bearer {%json:Authorization%}"

Cookie-Based Authentication (Session Cookies)

Some applications do not use tokens and instead rely on session cookies to maintain authentication.

This is common in server-rendered frameworks such as:

  • Django
  • Rails
  • PHP
  • Spring MVC
  • older Java applications

When login succeeds, the server creates a session and sends a cookie back to the browser using the Set-Cookie response header.

Example login response header:

Set-Cookie: SESSIONID=abc123xyz789; Path=/; HttpOnly

The browser stores this cookie and automatically includes it in all subsequent requests.

Example authenticated request:

Cookie: SESSIONID=abc123xyz789

DeepTraq replicates this behavior by extracting the cookie value from the login response.

Cookie extraction uses the placeholder syntax:

{%cookie:COOKIE_NAME%}

Example configuration:

Cookie: "SESSIONID={%cookie:SESSIONID%}"

This instructs the scanner to:

  1. Read the login response headers
  2. Locate the Set-Cookie header
  3. Extract the value of the specified cookie
  4. Include it in the Cookie request header

To determine the correct cookie name:

  1. Login normally in your browser
  2. Open Developer Tools → Network tab
  3. Select the login request
  4. Inspect the Response Headers

Look for the Set-Cookie header.

Example:

Set-Cookie: SESSIONID=abc123xyz789; Path=/; HttpOnly

In this case the cookie name is SESSIONID.

Configuration:

Cookie: "SESSIONID={%cookie:SESSIONID%}"

Next, inspect any authenticated request in the browser.

Developer Tools → Network → Request Headers:

Cookie: SESSIONID=abc123xyz789

The cookie name appearing before the equals sign must match the name used in the configuration.

Example 1 — Standard Session Cookie​

Login response:

Set-Cookie: SESSIONID=abc123xyz789

Authenticated request:

Cookie: SESSIONID=abc123xyz789

Configuration:

Cookie: "SESSIONID={%cookie:SESSIONID%}"

Example 2 — Java Applications (JSESSIONID)​

Login response:

Set-Cookie: JSESSIONID=ABCD1234EFGH5678

Authenticated request:

Cookie: JSESSIONID=ABCD1234EFGH5678

Configuration:

Cookie: "JSESSIONID={%cookie:JSESSIONID%}"

Example 3 — PHP Applications​

Login response:

Set-Cookie: PHPSESSID=xyz987abc654

Authenticated request:

Cookie: PHPSESSID=xyz987abc654

Configuration:

Cookie: "PHPSESSID={%cookie:PHPSESSID%}"

Important Notes

The cookie name used inside {%cookie:...%} must match the name returned in the Set-Cookie header.

Example:

Set-Cookie: SESSIONID=abc123

Correct configuration:

Cookie: "SESSIONID={%cookie:SESSIONID%}"

In most applications, the cookie name appearing in:

  • the Set-Cookie response header
  • the Cookie request header

is the same.

Example:

Set-Cookie: SESSIONID=abc123 Cookie: SESSIONID=abc123

This makes configuration straightforward.

Multiple cookies may be set​

Some login responses may set several cookies.

Example:

Set-Cookie: SESSIONID=abc123 Set-Cookie: CSRF-TOKEN=xyz987

Usually only the session cookie is required.

To determine the correct cookie:

  1. Inspect an authenticated request
  2. Identify which cookie is included in the Cookie request header
  3. Configure that cookie in the YAML file

Best Practice

Before configuring authentication headers:

  1. Login normally in the browser
  2. Inspect the login response
  3. Identify whether authentication uses tokens or cookies
  4. Replicate the same header structure in the YAML configuration

Matching the exact request structure used by the application ensures the scanner can maintain a valid authenticated session throughout the scan.