style
content

Custom HTTP Response Headers

In some cases, it is useful to apply custom HTTP response headers to resources, for example to allow CORS. Headers can be specified in the headers object of your site configuration like this:

{
  "/fragments/**": [
    {
      "key": "access-control-allow-origin",
      "value": "https://www.example.com"
    }
  ]
}

Try our HTTP Headers Editor or see here for instructions how to apply custom headers from your command line.

If your site does not use the configuration service yet, see here for legacy instructions.

The URL property is a glob pattern matching the pages the custom header should be applied to. A wildcard * can be used as a prefix or suffix, allowing for flexible matches on the URL pathname. You can use ** for deep path matching. Typical examples include /foo/** or **/bar/**.

Security Warning

Adding an access-control-allow-origin header with value * may render your protected preview and live environments vulnerable to CSRF attacks against authors logged in via AEM Sidekick, which can potentially lead to disclosure of sensitive information. If you do have a use case where it is not possible to restrict access to a single origin, try to limit the header to specific URLs to minimize the attack surface.

Note that the headers are applied to both the preview and live versions of the content. For changes applying to content, caches will be purged automatically and your changes will take effect immediately. If the changes apply to code resources, they won’t take effect until the next code sync, either by updating the code in the main branch of the repository or by manually triggering a resync via Admin API.