CORS Support in the Experience Cloud Identity Service cors-support-in-the-experience-cloud-id-service
Browsers use Cross Origin Resource Sharing (CORS) to request resources from a domain other than the current domain. The Experience Cloud Identity Service supports CORS standards that enable these client-side, cross-origin resource requests. The ID service reverts to JSONP requests on older browsers or browsers that do not support CORS.
Problems with Same-Origin Policies and ID Service Requests section-6608cf46d27143eeaeabacaa6aa14e8e
Same-origin policies are security controls or restrictions enforced by a web browser. When enforced on this level, the web browser itself determines if a request for resources made from one page to another will be permitted or blocked. To determine if a request is a same-origin request, the browser compares:
- Uniform Resource Identifiers (URIs)
- Host names (e.g., http://www.my-webpage-example.com)
- Port numbers (e.g., port 80 and 440 for HTTP and HTTPS requests)
The browser allows a request to succeed if both pages share these characteristics and blocks resource requests if they do not.
CORS Resolves Problems with Same-Origin Policies section-76c87ec3295d447bab220c84f138c235
CORS provides a secure, effective way to request resources across different domains. The CORS specification includes a set of HTTP headers that browsers use to send, receive, and evaluate resource requests. Evaluating a resource request is called a preflight check. This check lets browsers and servers determine which requests are allowed or blocked. The preflight check is transparent to the app, API, or script that requests a resource. Two headers that are important in the resource request process include:
Origin: A request header that identifies the source of a request.Access-Control-Allow-Origin: A response header that indicates if a resource can be shared with the requestor.
Let’s take a look at how these headers work. In this example, say we have a financial services company that has implemented the Experience Cloud ID service on their site, www.finance-website.com. The following table defines how the CORS request and response headers check for access to a resource.
As finance company page loads, the browser makes a request to dpm.demdex.net. This is a call to the domain of the data collection servers (DCS) used by the ID service. This cross-domain request includes the header:
- Origin//www.finance-website.com
The response from the DCS domain includes these headers that give the finance company's site access to required resources:
- Access-Control-Allow-Origin: https://www.finance-website.com
- Access-Control-Allow-Credentials: true
See also useCORSOnly.
Other Benefits of Using CORS section-6f44f30694c44f95bf9854b8a2af8449
The table below describes some of the advantages CORS provides to customers who use the ID service.
CORS uses XMLHttpRequest to request and transfer data. This method is more secure than a JSONP request. It ensures that there is no way to execute arbitrary JavaScript, which might be contained in the response from the DCS. The CORS XMLHttpRequest response payload is parsed by the ID service JavaScript and not simply executed in a callback function.
Note: To accept cookies, the XMLHttpRequest object needs its withCredentials property set to true. This property is supported in Chrome, Firefox, Internet Explorer (v10+), Opera, and Safari.
CORS helps improve performance because:
- The browser manages resource requests. The request process is transparent to the ID service.
- Unlike asynchronous JSONP requests, the browser does not de-prioritize and queue CORS requests.
- The ID service responds permissively. This means when a URL passed in as Origin, the ID service grants the page access to the required resources.