Mixed Content and CORS error for Access-Control-Allow-Origin, Mashup fails to load when deployed on web server

[Sonja_Bauernfeind]

A Mixed Content error and CORS errors are displayed in a Qlik Sense Enterprise on Windows Environment running HTTPS and a Webserver hosting a mashup on HTTP. 

Qlik Sense Mashups may fail to render when deployed to a web server. 

Example setup:

• Webapp server is running HTTP (e.g. in development)
• Qlik is running HTTPS only.

Example error messages:

Access to XMLHttpRequest at [] from origin '[]' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header has a value '[]' that is not equal to the supplied origin.

Origin null not found in Access-Control-Allow-Origin header.

XMLHttpRequest cannot load. No 'Access-Control-Allow-Origin' header is present on the requested resource. 

Resolution

Option 1:

Avoid mixed content (HTTP and HTTPS) 

Option 2:

First, verify that the host is included in the WebSocket origin allow list. For details on how this is configured, see How to configure the WebSocket origin allow list and best practices.

Example: A mashup is hosted on http://localhost:8080, and Qlik Sense is hosted on https://my-sense-server. Including "localhost" in the allow list is not sufficient; include explicitly both the protocol and port in this case (* will not include the port):

• http://localhost:8080
• https://localhost:8080

Then configure Qlik Sense (November 2018 and up) specifically to address the CORS error 

1. From Qlik Sense November 2018 and up, the Virtual Proxy allows for the configuration of the Additional response header for CORS protection.
2. Open the Qlik Sense Management Console.
3. Navigate to Virtual proxies
4. Select the Virtual proxy in use for the hub
5. Expand the Advanced properties
6. Configure the Additional response headers accordingly
   
   

   Note: Wildcard (*) is not supported. Always define the actual origin.

   

Example:  

Assuming that QlikServer1 is the Qlik Sense server running on HTTPS and localhost is the web server running on HTTP.

The additional response headers would be:

Access-Control-Allow-Origin:https://qlikserver1.domain.local, http://localhost

This issue originates from the browsers parsing and handling of the web content. As a security measure browser do not allow content from multiple domains unless the main page has been configured to allow the cross-domain content. The symptom of not allowed cross-domain content is that the embedded parts fail to render and the browser throws a Cross-Origin Resource Sharing (CORS) error. 

The main page must have a HTTP header that allows content from the Qlik Sense host, in order for the embedded object to be allowed by the browser. The general advice on (Access-Control-Allow-Origin) HTTP header requirements are as described in below link from Mozilla Developer Network.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
https://www.w3schools.com/tags/att_iframe_sandbox.asp 
 
If the allow list has been configured correctly in Qlik Sense, then the issue may lie in the web portal or web page hosting Qlik Sense content. Please contact the web service provider or web server administrator for further troubleshooting and configuration. 

Environment:

Qlik Sense Enterprise on Windows 

[christopherkramer]

Is `Access-Control-Allow-Origin` still required in Qlik Sense May 2025? I found it to be set automatically if I access a mashup from https://localhost:3000, the header is https://localhost:3000,  if I access it from https://localhost:3001,  it is https://localhost:3000.   If I access it from https://hostname/extensions/myextension/index.html   , the header is not there (as the origin is the same as the engine api requests, the header is not necessary).

If I set the header to "https://foobar" or "https;//localhost:3000", the behavior does not change at all, it still sets the header for port 3000 and 3001.

It seems it is set automatically and setting it in the virtual proxy has no effect at all.

(There is no HTTP proxy in between that could add the header.)

[christopherkramer]

Typo. Corection: if I access it from https://localhost:3001 ,  it is https://localhost:3001 

[Sonja_Bauernfeind]

Hello @christopherkramer 

I checked with one of our subject matter experts on this:

It's based on the host allow list; no need to input ports. Localhost and actual servername (not external DNS names) are automatically considered trusted, so you only need to add external DNS names or mashup server names to the allowlist.