iRule Approach to Mask Authorization Header for Bot Defense Logging – Validation Needed

Hi Muskan_Kafle​ ,

Nice work on the iRule,  You should check out F5's Irules Assistant - Irules Assistant.  I had it run through your iRule and here was the analysis:  

1. Objective
   • On each incoming HTTP request, mask the Authorization header before Bot Defense inspects or logs it.
   • Store the original Authorization value using the request sequence number as a key.
   • After Bot Defense processing but before sending to the backend pool, restore the original header.
   • Ensure keep-alive flows are handled by using HTTP::request_num to differentiate requests.
2. Execution Flow
   • Event HTTP_REQUEST (client-side):
   – Compute req_id via HTTP::request_num (doc: returns request count on this connection).
   – If an Authorization header exists (HTTP::header exists), save its value in auth($req_id) and replace it with a fixed masked string.
   • Event HTTP_REQUEST_RELEASE (server-side):
   – Compute req_id again with HTTP::request_num.
   – If auth($req_id) exists, replace the masked header with the stored original value and unset auth($req_id) to free memory.
3. Potential Logic Concerns
   • Global array collisions: using a single Tcl array auth() keyed only by request_num may overlap across simultaneous connections (each starts at 1), leading to cross-connection data mix-ups. (high confidence)

Overall Summary:
This iRule correctly intercepts and temporarily masks Authorization headers around Bot Defense processing, then restores them for the backend. The main caveat is potential key collisions in the shared auth array when multiple client connections have identical request_num values.