Forum Discussion
Bot Defense causing a lot of false positives
- Apr 14, 2026
Hi renaud-gaspard ,
The anomalies could be contributed due to Chromes third part deprecation. If that's in play you might want to consider using Cookies with Independent Partitioned state aka (CHIPs). This would be a modification to the irule and in chrome would need to have this setting ---> chrome://flags/#test-third-party-cookie-phaseout enabled.
Aside from the irule to test and try the issue with "High Number of HTML transactions since JS verification" there could be some tweaks to try for this.
HTML transactions since JS verification" threshold. The default is typically low (5-10). For SPAs returning HTML fragments, maybe try to set to 50-100 based on the traffic pattern.
Static resource paths wont carry cookies. Make sure these are exempt in the Bot Defense profile, add URL allowlist entries:
Pattern Type *.css Glob *.js Glob *.woff Glob *.woff2 Glob *.ttf Glob *.eot Glob *.svg Glob *.png Glob *.jpg Glob *.jpeg Glob *.gif Glob *.webp Glob *.ico Glob *.map Glob /static/* Glob /assets/* Glob /cdn-cgi/* Glob Adjust the path-based patterns (/static/*, /assets/*) to match your actual resource directory structure. You can also use regex if you need more refinement.
#--------------------------------------------------------------- # Purpose: Append SameSite=None; Secure; Partitioned to Bot # Defense (TS*) and persistence (BIGipServer*) cookies # to support cross-domain PBD under Chrome 3P cookie # deprecation (CHIPS). #--------------------------------------------------------------- when RULE_INIT { # Toggle debug logging: 1 = enabled, 0 = disabled (production) set static::cookie_debug 0 } when HTTP_RESPONSE_RELEASE { # Iterate over all Set-Cookie headers in the response # We must use "HTTP::header values" to capture multi-value # Set-Cookie headers — "HTTP::header value" only returns the first # Collect all Set-Cookie headers set num_cookies [HTTP::header count "Set-Cookie"] # Short-circuit if no cookies present if { $num_cookies == 0 } { return } # Build a list of modified cookies, then replace all at once # This avoids modifying the header collection while iterating set new_cookies [list] set modified 0 for { set i 0 } { $i < $num_cookies } { incr i } { set cookie [HTTP::header value "Set-Cookie" $i] # Match TS* (Bot Defense) and BIGipServer* (persistence) cookies if { [string match "TS*" $cookie] || [string match "BIGipServer*" $cookie] } { # Skip if already fully patched (idempotency guard) if { [string match "*Partitioned*" $cookie] } { lappend new_cookies $cookie continue } # Case 1: Has SameSite=None but may be missing Secure and/or Partitioned if { [string match "*SameSite=None*" $cookie] } { if { !([string match "*Secure*" $cookie]) } { append cookie "; Secure" } append cookie "; Partitioned" set modified 1 # Case 2: No SameSite attribute at all — add full attribute chain } else { append cookie "; SameSite=None; Secure; Partitioned" set modified 1 } if { $static::cookie_debug } { log local0.debug "CHIPS_IRULE: Patched cookie: $cookie" } } lappend new_cookies $cookie } # Only rewrite headers if we actually changed something if { $modified } { # Remove all existing Set-Cookie headers HTTP::header remove "Set-Cookie" # Re-insert all cookies (modified + unmodified) foreach c $new_cookies { HTTP::header insert "Set-Cookie" $c } } }
Hi renaud-gaspard ,
As you mentioned the TS Cookies which are domain scoped pose the issue when one site loads resource from another domain. I think the "SameSite" iRule can help this with a modification on where the "Set-Cookie" is placed, if we can adjust to cover all TS cookies on all responses this should help. Bot Defense injects its cookies after HTTP_RESPONSE so changing the event handler should cover this. I used F5's F5 AI Assistant - iRules to help validate the iRule code that can help with this scenario. I have not tested this so please do so in a non-prod environment.
when HTTP_RESPONSE_RELEASE {
foreach cookie [HTTP::header values "Set-Cookie"] {
if { [string match "TS*" $cookie] || [string match "BIGipServer*" $cookie] } {
if { !([string match "*SameSite=*" $cookie]) } {
HTTP::header replace "Set-Cookie" $cookie "$cookie; SameSite=None; Secure"
}
}
}
}
Here is what F5's AI Assistant for iRules, analyzed and explained for the iRule:
- Objective
• This iRule runs at the HTTP_RESPONSE_RELEASE event to inspect all outgoing Set-Cookie headers.
• It targets cookies whose names start with “TS” or “BIGipServer” and, if they lack any SameSite attribute, appends “; SameSite=None; Secure” to enforce cross-site usage and require secure transport. - Execution Flow
- Event HTTP_RESPONSE_RELEASE fires just before the BIG-IP releases the HTTP response to the client (see docs).
- The code retrieves every Set-Cookie header value via
foreach cookie [HTTP::header values "Set-Cookie"] - It checks if the cookie string begins with “TS” or “BIGipServer” ([string match "TS*" $cookie] || [string match "BIGipServer*" $cookie]).
- For each matching cookie, it tests absence of a SameSite attribute (!([string match "*SameSite=*" $cookie])).
- If no SameSite is found, it replaces that specific Set-Cookie header with a version that appends “; SameSite=None; Secure” using
HTTP::header replace "Set-Cookie" $cookie "$cookie; SameSite=None; Secure".
- Potential Logic Concerns
• If a matching cookie already has a SameSite attribute but lacks the Secure flag, this rule will skip it entirely and not add Secure. (high confidence)
Summary
The iRule correctly identifies and modifies specified persistence cookies to include SameSite=None and Secure in most cases, but it will not add Secure to cookies that already declare a SameSite attribute.
Under Cross-Domain-Request config -make sure this is set: Allow configured domains; validate upon redirect.
All FQDN's that server cross-domain should be in the site domain list. For example where you see <script src> and other reference tags that contain domains.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com