Cross-Origin Resources Sharing (CORS) is a case where an application running in a Web Browser, loaded from a certain origin (domain) is trying to access selected resources from a different domain.

The below diagram depicts a simplified architecture:


In the diagram we have the following setup:

  1. A Web Application with external address of
  2. REST API Server, defined as a Web Application with external address of
  3. AJAX inside the Web Application that tries to call a REST API Server

Modern Web Browsers are treating cross-origin resources sharing as a sensitive activity and are enforcing strict security policy for the following operations:

In this article we will focus on AJAX calls made using XMLHttpRequest.

Since both the Web Application and the REST API Server are protected by the Luminate Secure Access Cloud (TM) Zero Trust Access capabilities, in order for the AJAX call from a document loaded from the Web Application to call the REST API Server successfully, following conditions need to be met:

1. Access-Control-Allow-Origin header for the responses from the REST API Server should be set to (in order to allow access to this resource from resources loaded from the Web Application). It can be set to the same value for the Web Application as well.

2. Access-Control-Allow-Credentials header should be set to "true". This is particularly important due to the Zero Trust nature of the access to the REST API Server. The call made by AJAX code running in the browser should forward the credentials of the Luminate-authenticated and authorized user (that is using the Web Application) to the REST API Server for identity-based access control. Without this head set explicitly to "true", the browser will refuse to lend "credentials" to the call, resulting in the Zero Trust access rejecting it.

3. The XMLHttpRequest from AJAX should be sent with "withCredentials" property set to "true" in order to ask the Web Browser to use the authorized credentials for the Web Application session to be forwarded to the REST API Server request.

4. The user (that is using the Web Application) should be authorized in Luminate to access the REST API Server as well.

What if we cannot influence CORS Headers and XMLHttpRequest parameters?

If, for some reason, there is no configuration on the Web Application / REST API Server side that can make sure that the CORS Policy Headers and the XMLHttpRequest attributes are set accordingly, the only way to make a configuration work is to expose both resources under the same origin/domain.

There are two ways of achieving this:

1. Deploying a proxy behind the connector that sends various URI locations to different servers:


The Facade proxy could be a very simple component based on a lightweight NGINX or a similar web proxy, forwarding all traffic that refers to REST APIs to the REST API Server and all the rest to the Web Application server.

2. Using a built-in redirection capability in Luminate Secure Access Cloud (M)


In case deploying a proxy internally is challenging or impossible, Luminate Secure Access Cloud (TM) offers a special capability that allows providing access to URIs inside REST API Server via an origin that belongs to the Web Application. In order to use this capability, the URIs need to be preceded with a /<special-redirection-directive>/ prefix (the rest of the URI should be after an additional "/", translating the call of to<special-redirection-directive>/

Please note that, despite the fact, that the resources of a REST API Server are now being served under the origin/domain of the Web Application Server, access to them is still subject to an Access Policy of the Web Application, as defined in Luminate Admin Portal.

As implementing such redirection may impact sensitive services, please reach out to Luminate Support at [email protected] to consult about using this capability.