Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Clear all filters

ASM Transparent mode blocking CORS requests

Hello community,

I would like to know if anyone have seen or had an issue with CORS (Cross-Origin Resource Sharing) and ASM, i have an problem with Javascript request that its been blocked by CORS policy on browser when i assign the the ASM profile on the virtual server, the main issue is that the ASM profile its an newly created ASM policy in transparent mode (It should not block anything), and i can not see any violation on the ASM>Events Logs.

Im sure that the ASM profile its causing this issue with the site, i made some tests and after removing the ASM profile from the virtual server there is no error from CORS in the browser. I also have searched abou this on DevCentral and found that this feature its from Proative Bot Defense, and its configured in DoS Profile, the problem is that i do not have an DoS profile on the virtual server, and its has became very diffcult to find the root cause of this.

Here iss on example of the request blocked in Google Chrome when the ASM profile its assign:

Access to XMLHttpRequest at 'https://app.host-a.com/Geral/MasterPage?pais=a` from origin 'https://www.host-b.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Do you guys have a clue were should i search for this strange behaviour ?

Rate this Question
Comments on this Question
Comment made 3 months ago by Hugo Frauches 133

Just found out that the ASM its removing the Security Headers from response, and then causing CORS erros for the clients.

Removed Headers:

Access-Control-Allow-Origin: https://www.app.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type, *

in fact the headers are presented in HTTP_RESPONSE (APP>F5) but are removed in HTTP_RESPONSE_RELEASE (F5>CLient) by ASM.

Could this be an BUG or some feature by design? Because ASM transparent mode should not block/change anything in the request...


Answers to this Question


Hi Hugo,

Thanks for the update. I agree, this is unacceptable. Never encountered something like this with ASM and I have dealt with CORS many times before. You can play with the CORS configuration through ASM or with an irule, I think that this is what I will do.


Stumbled upon very similar issue yesterday. When ASM is configured( simple profile ) even in transparent mode, users on mobile chrome receive CORS error on certain iframes. When ASM is disabled, everything works flawlessly. Need to verify if ASM is striping down the CORS headers...

Comments on this Answer
Comment made 3 months ago by Hugo Frauches 133

Hello Alex,

In fact the ASM does this, the F5 support told me this its by design on ASM:

"If you do not enable cross-domain request enforcement, the system removes all cross-origin request headers and CORS is not allowed for the URL."

For me this its unacceptable, F5 ASM shouldnt do this by default, because we have an feature called "transparent mode" and this CORS protection should be disabled and allowing * (Wildcards) by default. I have requested an RFE for this.

Comment made 1 month ago by rodolfosalgado 55

I just had the same problem in my F5 BIG IP ASM If I remove the WAF everything works flawless, I would expect at least the WAF in transparent mode to work but that isn't the case either...

Comment made 4 weeks ago by rodolfosalgado 55

After opening a ticket with the F5 they gave the following irule as solution (known bug = https://support.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/related/relnote-supplement-bigip-14-1-0-1.html#A746394-1):

Setup an irule on a virtual server:

    array set header_list { }
    foreach header_name [HTTP::header names] {
        if { [string tolower $header_name] starts_with "access-control-" } {
            set header_list($header_name) [HTTP::header $header_name]
    foreach header_name [array names header_list] {
        if {!([HTTP::header exists $header_name])} {
            HTTP::header insert $header_name $header_list($header_name)
Comment made 4 weeks ago by Alex.Nimo 145

Thanks for the update!