Bot Defense causing a lot of false positives

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:

1. 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.
2. 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".

1. 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.