Tracking

Tracking is a core identification framework that enables FortiWeb to maintain stateful visibility over client interactions. By mapping transient HTTP requests to stable session identifiers, the system facilitates deep request correlation across traffic logs, attack logs, and advanced security modules.

Tracking Modules

FortiWeb utilizes a multi-layered architecture to construct and manage session identities. These modules are evaluated in a fixed, hierarchical order. When a request is processed, the system attempts to identify the session using the highest-priority module first; if a valid identifier is successfully generated, it is utilized for logging and policy enforcement, and lower-priority evaluation is bypassed.

Priority	Module	Functional Logic	Best Use Case
1	Custom Tracking	High-Fidelity Hash Generation: Normalizes and hashes attributes extracted directly from application-defined HTTP fields such as headers, parameters, or response codes. See Custom Tracking.	Environments with non-standard or proprietary identifiers, such as API keys, X-User-ID headers, or scenarios requiring tracking based on specific server response behaviors.
2	User Tracking	Authenticated Session Mapping: Captures usernames and session tokens (e.g., PHPSESSID, JSESSIONID) during the login sequence to track stateful interactions. See User Tracking.	Standard web applications utilizing traditional HTML or JSON login forms and conventional session cookies.
3	Site Publish	Authentication Metadata Fallback: Leverages identity metadata retrieved from offloaded authentication or Single Sign-On (SSO) handshakes managed by the WAF. See To configure offloaded authentication with optional SSO.	Applications utilizing FortiWeb as an authentication gateway or those integrated into a broader SSO portal environment.
4	Certificate Forwarding	PKI-Based Identity Extraction: Derives user identity from the cryptographic attributes provided in client-side X.509 certificates. See Configuring an HTTP server policy and To configure client PKI authentication .	High-assurance environments requiring Mutual TLS (mTLS) or hardware-token-based client authentication.

Custom Tracking

Custom Tracking allows you to define unique tracking identifiers using a combination of HTTP attributes. This is designed for environments where applications provide their own identifiers that traditional tracking cannot capture.

How Custom Tracking Works

Custom Tracking extracts values from configured request or response parameters and normalizes them into a deterministic hash key. This ID is recorded in attack and traffic logs as the custom_tracking_id.

• Normalization: To ensure stable ID generation, parameters are ordered in a fixed sequence before hashing:

  Source IP > URL Path > Request URL Parameter > Request Cookie > Request Header > Request Body > Response Header > Response Code

• Generation Logic:

  • track-only-when-all-matched: Generate an ID only when all match conditions defined in the policy are present in the request or response (Default: Enabled).

  • bypass-when-none-matched: Skip ID creation when none of the selected attributes appear in the traffic (Default: Enabled).

To create a Custom Tracking policy:

1. Go to Tracking > Custom Tracking.

2. Click Create New to display the configuration editor.

3. Enter a Name that identifies the Custom Tracking policy.

4. Define the Tracking Timeout in minutes. The default value is 30, and the valid range is 1–1440.

5. Click OK to save the policy.
   Once saved, the Policy section becomes available to configure.

6. Under the Policy section, click Create New to add tracking parameters as match conditions and click OK.

   Each parameter type contributes differently to the tracking ID and includes specific constraints for how it can be used in a policy:

   Tracking Parameter	How It Is Used	Rules and Constraints
   Source IP	Uses the client IP address to help identify the requester.	Can appear only once. No name or pattern required.
   URL Path	Matches or extracts portions of the request path.	Supports plain or regex matching. Regex cannot be empty.
   Request URL Parameter	Extracts a value from the query string.	Requires a non-empty parameter name. Name cannot be reused. Supports plain or regex.
   Request Body Parameter	Extracts a value from the request body.	Requires a non-empty parameter name. Name cannot be reused. Supports plain or regex.
   Request Cookie	Uses a cookie value supplied by the application.	Requires a non-empty cookie name. Name cannot be reused. Supports plain or regex.
   Request Header	Uses a request header such as X-User-ID or Authorization.	Requires a non-empty header name. Name cannot be reused. Supports plain or regex.
   Response Header	Extracts a value from response headers.	Requires a non-empty header name. Supports plain or regex.
   Response Code	Matches the HTTP response status returned to the client.	Can appear only once. Requires a min and max code range. No regex or name.

7. Click OK again to save the policy.

Tracking ID Generation

For each relevant request or response, FortiWeb extracts the configured parameter values, normalizes them, orders them in a fixed sequence, and generates a deterministic hash key. This ensures that tracking IDs remain stable even when header ordering or request formatting varies.

Two CLI-only options refine when FortiWeb creates tracking IDs:

• track-only-when-all-matched (default enabled): Generate an ID only when all match conditions are present.

• bypass-when-none-matched (default enabled): Skip ID creation when none of the selected attributes appear.

CLI command:

config waf custom-tracking policy
    edit <policy_name>
        set tracking-timeout <integer>
        set track-only-when-all-matched {enable|disable}
        set bypass-when-none-matched {enable|disable}
        config match-condition
            edit <id>
                set match-target {source-ip|url|request-url-parameter|request-body-parameter|request-cookie|request-header|response-header|response-code}
                set target-name <string>
                set target-value-type {plain|regular}
                set target-value-regex <string>
                set response-code-min <integer>
                set response-code-max <integer>
            next
        end
    next
end

User Tracking

The user tracking framework captures a username and session ID when a user matches specific criteria in a tracking policy. This is primarily used for applications with standard web-based login forms.

User Tracking Lifecycle

• Determining Successful Logins: FortiWeb exclusively tracks users who have successfully authenticated with the backend application. Identification of success is based on the Authentication Result Condition Table, where you define matching return codes or strings in the response body.

• Termination of Tracking: FortiWeb ceases tracking a session if the client sends a request matching the optional Log Off URL or if the session remains inactive longer than the Session Idle Timeout.

• Session Timeout Enforcement: If enabled, FortiWeb can "freeze" a session ID for a specified duration after it has timed out. Any request presenting the timed-out ID during this freeze period triggers the configured enforcement action (e.g., Alert or Deny).

Advanced Protection Integration

User tracking data can be leveraged to create granular filters within Advanced Protection custom rules. This allows you to create rules that match specific tracked users, provided the tracking policy is applied to the same web protection profile used by the custom rule.

For details, see Custom Policy.

You can apply a user tracking policy using either an inline or Offline Protection profile. However, in Offline Protection mode, Session Fixation Protection, Session Timeout Enforcement, and the deny, redirect and period block actions are not supported.

To create a user tracking policy

1. Go to Tracking > User Tracking, and select the User Tracking Rule tab.
2. Click Create New, and then complete the following settings:
   

Name	Enter a name that identifies the rule.
Host Status	Enable to require that the Host: field of the HTTP request match a protected host names entry in order to match the URL access rule. Also configure Host.
Host	Select which protected host names entry (either a web host name or IP address) that the Host: field of the HTTP request must be in to match the rule. This option is available only if Host Status is enabled.
Authentication URL	Enter the URL to match in authorization requests. Ensure that the value begins with a forward slash ( / ).
Username Field	Enter the username field value to match in authorization requests.
Password Field	Enter the password field value to match in authorization requests.
Session ID Name	Type the name of the session ID that is used to identify each session. Examples of session ID names are sid, PHPSESSID, and JSESSIONID. To track users with JSON format login credentials, here you need to type the API token in response data that users will use to access server resource in API queries.
Default Authentication Result	Enter the authentication result that FortiWeb associates with requests that match the criteria but do not match an entry in the Authentication Result Condition Table. When the login result is successful, FortiWeb tracks the session using the session ID and username values.
Log Off URL	Optionally, enter the URL of the request that a client sends to log out of the application. When the client sends this URL, FortiWeb stops tracking the user session. Ensure that the value begins with a forward slash ( / ).
Session Fixation Protection	Enable to configure FortiWeb to erase session IDs from the cookie and argument fields of a matching login request. FortiWeb erases the IDs for non-authenticated sessions only. For web applications that do not renew the session cookie when a user logs in, it is possible for an attacker to trick a user into authenticating with a session ID that the attacker acquired earlier. This feature prevents the attacker from accessing the web app in an authenticated session. When this feature removes session IDs, FortiWeb does not generate a log message because it is very common for a legitimate user to access a web application using an existing cookie. For example, a client who leaves his or her web browser open between sessions presents the cookie from an earlier session. Caution: This option is not supported in Offline Protection mode.
Limit Concurrent Users Per Account	Enable to limit the number of concurrent logins per account. The active accounts are shown in Active Users page. To view it, click the Add Monitor icon in the navigation bar, then click the Add icon before Active Users. .
Maximum Concurrent Users	Specify the maximum number of concurrent logins using the same account. The valid range is 1-128.
Session Idle Timeout	When a session is idled for the specified period of time, the Concurrent Users count will be renewed. The user who is timed-out needs to re-log in.
Session Timeout	Enable to set the time in minutes that FortiWeb waits before it stops tracking an inactive user session.
Timeout	Enter the length of time in minutes. Valid values are from 1 to 60.
Session Timeout Enforcement	Disable to configure FortiWeb to remove the session ID for user sessions that are idle for longer than the session timeout threshold. When a session is reset, the client has to log in again to access the back-end server. Enable to configure FortiWeb to freeze the session upon the first request after session timeout. FortiWeb takes the specified action, for a length of time specified by Session Freeze Time. Caution: This option is not supported in Offline Protection mode. It is available only when Session Timeout is enabled.
Credential Stuffing Defense	Enable to use FortiGuard's Credential Stuffing Defense database to prevent against Credential Stuffing attacks. When this setting is enabled, FortiWeb will evaluate the username (Username Field) and password (Password Field) of the matched login requests against the Credential Stuffing Defense database to identify whether the paired username/password has been spilled. If it has, the specified Action triggers and the Trigger Policy is applied. Caution: FortiWeb has no built-in Credential Stuffing Defense database. At least one FortiGuard update is required to install the database, otherwise this feature is ineffective. For details, see Connecting to FortiGuard services.
Credential Stuffing Online Check	Enable to execute Credential Stuffing Defense using an online query in addition to the local DB query. The online database is larger and covers additional leaked credentials from data breaches. To verify whether this feature works properly, you can click the Test button and enter a user name and password which you believe is a malicious user, then check the scan result returned by the system.
Test	To verify whether the local or online Credential Stuffing database works properly, you can click the Test button and enter a user name and password which you believe is a malicious user, then check the scan result returned by the system.
Session Freeze Time	FortiWeb freezes the session upon the first request after session timeout. Enter the length of the freeze time. FortiWeb takes action against requests with the ID of the timed-out session during the specified freeze time. After the freeze time has elapsed, FortiWeb removes the session ID for idle sessions but no longer takes the specified action. Available only when Session Timeout Enforcement is enabled.
Action	Select the action that FortiWeb takes against requests with the ID of a timed-out session during the specified time period or if the paired username/password is found in Credential Stuffing Defense database: Alert—Accept the request and generate an alert email and/or log message. Alert & Deny—Block the request (or reset the connection) and generate an alert email and/or log message. You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages). Note: Because the deny action is not supported in Offline Protection mode, this option has the same effect as Alert. Deny (no log)—Block the request (or reset the connection). Redirect—Redirect the request to the URL that you specify in the protection profile and generate an alert and/or log message. Also configure Redirect URL and Redirect URL With Reason. Caution: This option is not supported in Offline Protection mode Period Block—Block subsequent requests from the client for a specified number of seconds. You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages). Caution: This option is not supported in Offline Protection mode When the action generates a log message, the message field values will be: Session Timeout Enforcement message: Session Timeout Enforcement: triggered by user <username>. Credential Stuffing Defense Violation message: Triggered by user <username>: Credential Stuffing Defense Violation. Available only when Session Timeout Enforcement and/or Credential Stuffing Defense is On.
Block Period	Type the number of seconds that you want to block requests with the ID of a timed-out session. This setting is available only if Action is set to Period Block. The valid range is from 1 to 3,600 seconds (1 hour). See also Blocked IPs.
Severity	When the session timeout settings or credential stuffing defense generates an attack log, each log message contains a Severity Level (severity_level) field. Select which severity level FortiWeb uses when it takes the specified action: Informative Low Medium High The default value is Low. Available only when Session Timeout Enforcement and/or Credential Stuffing Defense is On.
Trigger Policy	Select which trigger, if any, that FortiWeb uses when it logs or sends an alert email about the session timeout or credential stuffing hit. See Configuring triggers. Available only when Session Timeout Enforcement and/or Credential Stuffing Defense is On.

When both Session Timeout （Session Timeout Enforcement enabled）and Credential Stuffing Defense are enabled, violations of any of the two security events will trigger the same actions (they use a common set of configurations: Action, Block Period, Severity and Trigger Policy).

3. Click OK.
4. To add an entry to the Authentication Result Condition Table, click Create New, and then complete the following settings:

Authentication Result Type	Specify the status FortiWeb assigns to user logins that match this table item: Failed or Successful. FortiWeb tracks sessions by user only when the status is Successful. If the request does not match any rules in this table, FortiWeb uses the value specified by Default Authentication Result.
HTTP Match Target	Select the location of the value to match with the string or regular expression specified in this table item: Return Code, Response Body, Redirect URL.
Value Type	Indicate whether Value is a Simple String or a Regular Expression.
Value	Enter the value to match.

5. Click OK, and then add any additional table entries that are required.
   
6. Create any additional rules that are required.
7. To add the rules to a policy, go to Tracking > User Tracking, select the User Tracking Policy tab, click Create New, enter a name for the policy, and then click OK.
8. Click Create New, select the user tracking rule to add, and then click OK.
9. Add any additional rules that are required, and then click OK.
10. To apply the user tracking rule, select it in an inline or Offline Protection profile. For details, see Configuring a protection profile for inline topologies or Configuring a protection profile for an out-of-band topology or asynchronous mode of operation.

Monitoring Tracked Activity

Once a tracking policy is active, you can observe real-time activity through dashboard monitors:

• Custom Tracking: Displays active tracking IDs, the most recent client IP associated with each ID, the server policy used, and the specific parameters that formed the hash.

• Active Users: Lists users currently identified by the User Tracking and Site Publish modules.

• Blocked Users: Provides visibility into clients currently blocked due to tracking violations, such as session timeouts or concurrent login limits.

• Client Management: Monitors cookie-based identifiers and provides risk levels and access statistics. See Client Management.