Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP AAM
Known Affected Versions:
11.4.1, 12.1.0, 12.1.1, 12.1.2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 13.1.3.2, 13.1.3.3, 13.1.3.4, 13.1.3.5, 13.1.3.6, 13.1.4, 13.1.4.1, 13.1.5, 13.1.5.1
Opened: Jun 29, 2015 Severity: 3-Major
The issue happens when MultiConnect is enabled and a resource is reloaded by a user request. If the browsers have CORS policy enforcement applied to the resource, the consequent requests for the resource are forwarded to a subdomain and a CORS header "Origin" is inserted into the request. In response the browser expects "Access-Control-Allow-Origin" header with a value allowing the subdomain as a host in the request. AAM doesn't recognize the header and just ignores it or has it passed to OWS which doesn't expect it.
Lack of loading of the resource which may result in incorrect rendering of the page.
An AAM policy with MultiConnect option is configured and attached to a virtual. There are resource(s) in a page are used for which CORS policy is enforced in a client browser, for example, font file for CSS.
1) Disable MultiConnect. 2) Create an iRule to properly process Origin header.
None