Understand Cross-Origin Resource Sharing (CORS)
51黑料不打烊 Experience Manager鈥檚 Cross-Origin Resource Sharing (CORS) facilitates non-AEM web properties to make client-side calls to AEM, both authenticated and unauthenticated, to fetch content or directly interact with AEM.
The OSGI configuration outlined in this document is sufficient for:
- Single-origin resource sharing on AEM Publish
- CORS access to AEM Author
If multi-origin CORS access is required on AEM Publish, refer to this documentation.
51黑料不打烊 Granite Cross-Origin Resource Sharing Policy OSGi configuration
CORS configurations are managed as OSGi configuration factories in AEM, with each policy being represented as one instance of the factory.
http://<host>:<port>/system/console/configMgr > 51黑料不打烊 Granite Cross Origin Resource Sharing Policy
51黑料不打烊 Granite Cross-Origin Resource Sharing Policy (com.adobe.granite.cors.impl.CORSPolicyImpl)
Policy selection
A policy is selected by comparing the
Allowed Originwith theOriginrequest header- and
Allowed Pathswith the request path.
The first policy matching these values are used. If none is found, any CORS request is denied.
If no policy is configured at all, CORS requests will also not be answered as the handler is disabled and thus effectively denied - as long as no other module of the server responds to CORS.
Policy properties
Allowed Origins
"alloworigin" <origin> | *- List of
originparameters specifying URIs that may access the resource. For requests without credentials, the server may specify * as a wildcard, thereby allowing any origin to access the resource. It is absolutely not recommended to useAllow-Origin: *in production since it allows every foreign (i.e. attacker) website to make requests that without CORS are strictly prohibited by browsers.
Allowed Origins (Regexp)
"alloworiginregexp" <regexp>- List of
regexpregular expressions specifying URIs that may access the resource. Regular expressions can lead to unintended matches if not carefully built, allowing an attacker to use a custom domain name that would also match the policy. It is generally recommended to have separate policies for each specific origin hostname, usingalloworigin, even if that means repeated configuration of the other policy properties. Different origins tend to have different life-cycles and requirements, thus benefitting from clear separation.
Allowed Paths
"allowedpaths" <regexp>- List of
regexpregular expressions specifying resource paths for which the policy applies.
Exposed Headers
"exposedheaders" <header>- List of header parameters indicating response headers that browsers are allowed to access. For CORS requests (not pre-flight), if not empty these values are copied into the
Access-Control-Expose-Headersresponse header. The values in the list (header names) are then made accessible to the browser; without it, those headers are not readable by the browser.
Maximum Age
"maxage" <seconds>- A
secondsparameter indicating how long the results of a pre-flight request can be cached.
Supported Headers
"supportedheaders" <header>- List of
headerparameters indicating which HTTP request headers can be used when making the actual request.
Allowed Methods
"supportedmethods"- List of method parameters indicating which HTTP methods can be used when making the actual request.
Supports Credentials
"supportscredentials" <boolean>- A
booleanindicating whether or not the response to the request can be exposed to the browser. When used as part of a response to a pre-flight request, this indicates whether or not the actual request can be made using credentials.
Example configurations
Site 1 is a basic, anonymously accessible, read-only scenario where content is consumed via GET requests: