Forum Discussion
iRule Approach to Mask Authorization Header for Bot Defense Logging – Validation Needed
I am working on masking sensitive information (specifically the Authorization header) from being exposed in Bot Defense logs on F5 BIG-IP Bot Defense, as there is currently no native feature available to mask the BOT request.
To address this, I have implemented the following iRule:
when HTTP_REQUEST {
# Unique ID per request (handles keep-alive correctly)
set req_id [HTTP::request_num]
if {[HTTP::header exists "Authorization"]} {
# Save original header for later restore
set auth($req_id) [HTTP::header value "Authorization"]
# Mask BEFORE Bot Defense inspects/logs
HTTP::header replace "Authorization" "Bearer *******************************************************************************"
}
}
when HTTP_REQUEST_RELEASE {
# This runs AFTER Bot Defense logging but BEFORE server send
set req_id [HTTP::request_num]
if {[info exists auth($req_id)]} {
# Restore original header for the application
HTTP::header replace "Authorization" $auth($req_id)
# Clean up memory
unset auth($req_id)
}
}
Is this iRule approach valid and reliable? Any suggestions for improvement or enhancement would be greatly appreciated.
1 Reply
- Jeff_Granieri
Employee
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:
- 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. - 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. - 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. - Objective
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