CORS in SCAPI
Currently, CORS is not supported for SLAS endpoints. Therefore, shopper login in a CORS context is not possible. Additional documentation will be provided as information becomes available.
CORS allows a web service to establish exceptions to the same-site policy that browsers normally enforce. Without CORS, browser access to resources on other servers is possible, but the browser prevents the response from being accessed and processed by the script.
When a browser requests a resource from a site whose domain is different from the site where the script is executed, an Origin header is added to the request. A server supporting CORS returns the response header Access-Control-Allow-Origin, which contains a list of origins that are allowed to use the endpoint. If the current origin is not part of the list, the browser prevents the content from being accessed.
The following image shows the request flow for a server named bar.com that supports CORS:
Browsers automatically make preflight requests before a modifying request is executed. Each preflight request is made as an OPTIONS request with the Origin header and the Access-Control-Request-Method header.
The resulting CORS response contains the Access-Control-Allow-Methods header, which lists the methods that the client is allowed to execute from the origin.
The modifying request itself is then only executed if the preflight request is successful, as shown in the following example request flow:
As of B2C Commerce 24.8, SCAPI adheres to the CORS standard and security best practices, and supports CORS requests for all Data and Shopper API endpoints.
Preflight (OPTIONS) requests are also supported.
If no configuration is provided, CORS is not active. To configure CORS in SCAPI, use the CORS API.
The configured list of aliases is automatically enriched with all known default names and site aliases. You do not need to explicitly configure them for CORS.
For security reasons, wildcards (*) are not supported, and the returned Access-Control-Allow-Origin header does not contain the full list of allowed origins. It only contains the single origin that was submitted with the current request’s Origin header.
The configuration of allowed CORS origins is unique to each environment and is not replicated between environments. The configuration of allowed origins is done per client ID and site, which means:
- You can maintain separate lists of allowed origins for different applications.
- You cannot have individual API or endpoint configurations.
The CORS API requires an AM OAuth token with the scope sfcc.cors-preferences.rw. When you send a new CORS configuration with a PUT request, the response mirrors the stored configuration, for example:
To enable CORS for a client without specifying custom origins, configure the client and site with an empty origin list. Known domain names and aliases still apply.
A CORS request, for example: a GET, PUT, POST, DELETE, or HEAD request, yields the same result as a typical request:
If a request contains a valid Origin header, the response contains the following headers:
If a request contains an invalid Origin header, these response headers are simply missing, with no other changes.
Note: This behaviour is different from OCAPI CORS where a manipulating request with an invalid origin results in a 401 status code and the message Unauthorized Origin.
For preflight requests with a valid endpoint, the server returns a 200 Success status with the following headers:
If the endpoint is invalid, the call will return a 404 Not Found status.
Custom APIs are not currently supported.