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 ?

application delivery

ASM Advanced WAF

security

Alex_Nimo_26616
Dec 16, 2018
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.

Hugo_Frauches_2
Cirrus
Dec 12, 2018
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...
Alex_Nimo_26616
Altocumulus
Dec 13, 2018
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...
- Hugo_Frauches_2
  Cirrus
  Dec 13, 2018
  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.
- rodolfosalgado_
  Altostratus
  Feb 20, 2019
  I just had the same problem in my F5 BIG IP ASM 14.1.0.1. 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...
- rodolfosalgado_
  Altostratus
  Feb 20, 2019
  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.htmlA746394-1😞
  
  Setup an irule on a virtual server:
  
  when HTTP_RESPONSE { 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] } } } when HTTP_RESPONSE_RELEASE { foreach header_name [array names header_list] { if {!([HTTP::header exists $header_name])} { HTTP::header insert $header_name $header_list($header_name) } } }
Alex_Nimo_26616
Altocumulus
Dec 16, 2018
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.
Walter_Kacynski
Cirrostratus
Apr 29, 2019
If you have a limited number of URL, you can selectively add them to your ASM policy and more CORS enforcement into the policy.
samstep
Cirrocumulus
May 01, 2019
This looks like a known issue with ASM v 14.x

Bug ID 746394: With ASM CORS set to 'Disabled' it strips all CORS headers in response.

https://cdn.f5.com/product/bugtracker/ID746394.html
Jim_M
Cirrus
Oct 14, 2020
The bugfix says its fixed in 14.1.2.1. But i still see it in 14.1.2.6
- Ivan_Chernenkii
  Employee
  Oct 29, 2020
  What build do you have?
  Do you see the same behavior - no removing CORS headers without ASM and removing, in case of attach ASM policy?
  What do you have in "HTML5 Cross-Domain Request Enforcement" tab for URL with CORS headers?
  
  Thanks, Ivan