Security Headers works in dev and stage environments, but does not work in Production.

[EvertonSa2]

Hello!

I need to implement Security Headers in the PROD environment, but it is not working, but it works in the developer and stage environments.

I use the website https://securityheaders.com/ to validate if the Headers are working and it returns a grade of F (no headers implemented) in the prod url, but returns a grade of A (excellent implementation) in the dev and stage publish links.

All my backend files in the dev, stage and prod environments are the same, with the same implementations, but the headers only appear in the dev and stage publish, they do not appear in the Prod environment.

[narendiran_ravi]

Which version of AEM are you using?

If your PROD URL is not served over HTTPS, that’s likely the reason some security headers—especially HSTS (Strict-Transport-Security)—are missing or ineffective.

 Things to Check:

• Is your PROD URL served over HTTPS?
• If not, HSTS and some other headers won't be valid.
• Check if the security headers are correctly configured in your CDN (e.g., CloudFront, Akamai) or dispatcher configs.
• Ensure the rules are properly applied in the PROD environment.
• Some CDNs may strip or override headers—ensure this isn’t happening.
• Open your browser’s Developer Tools → Network tab
• Inspect the Response Headers for your PROD URL to verify which headers are missing or misconfigured.

[EvertonSa2]

Hello!

How can I check which version of AEM I am using? Unfortunately, I don't know which version I am using.

The site has a URL that starts with both http and https, and both in dev and stage the security headers are displayed in the dev tools header, but the prod one does not return the headers.

All the headers are missing in the PROD URL.

The security headers are configured correctly in the dispatcher settings.

[SantoshSai]

Hi @EvertonSa2,

Looking into the screenshot you shared you are using AEM as a Cloud Service.

In AEM as a Cloud Service, security headers are injected via Adobe's edge CDN (even for publish URLs like https://publish-<env>.adobeaemcloud.com), not by the application code directly.

Also, you should test the public-facing domain (i.e., the actual domain where your site is accessible to end users) - not your internal author/publisher domains.

Here’s how you can debug missing headers:

1. Use curl

curl -I https://www.example.com

• This will show you all HTTP response headers from the final endpoint (CDN or Dispatcher).

• Check if headers like X-Content-Type-Options, Content-Security-Policy, X-Frame-Options, etc. are missing.

2. Use Chrome DevTools

• Open your site in Chrome.

• Go to DevTools > Network tab → Reload the page → Click the document request (your main HTML).

• Look under the Headers > Response Headers section.

• See what headers are returned.

3. Compare Dispatcher vs CDN (Akamai/CloudFront)

• Hit your Dispatcher directly (e.g., dispatcher.prod.example.com) and compare it to www.example.com.

• This helps check if the issue is on AEM/Dispatcher vs. CDN layer.

• Some headers may be stripped/added by the CDN, depending on config.

4. Akamai Debug Headers

If you use Akamai:

• Add a query param like ?akamai-debug=true or enable edge debugging if allowed.

• This will reveal if Akamai is adding/modifying headers.

[EvertonSa2]

Looking at the link https://publish-<env>.adobeaemcloud.com in DevTools, the titles are all ok in the PROD environment. However, when looking at the link to the website that the general public accesses (http://example.com), it does not return any headers.

[SantoshSai]

This discrepancy is almost always caused by intermediate infrastructure (typically a CDN or WAF) between AEM Publish and the public domain.

What You Can Do (Self-Serviced)

You can configure and debug some things yourself:

1. Verify CDN Setup via cdn.yaml

• If you’re using Adobe’s default CDN (Fastly), you can control caching, headers, etc., using cdn.yaml in your Cloud Manager project.

• Make sure you’ve configured security headers in cdn.yaml.
  Example:

  rules:
    - path: "/*"
      headers:
        - name: "Content-Security-Policy"
          value: "default-src 'self'"
        - name: "X-Content-Type-Options"
          value: "nosniff"

• After making changes, deploy the updated cdn.yaml through Cloud Manager.

2. Check Dispatcher Configs

• Security headers can also be set in the dispatcher layer (dispatcher/src/conf.d/variables/custom.vars or header files).

• But remember: if you see the headers when hitting publish-<env>, your AEM + dispatcher configs are already fine.

3. Test Public Domain

Use:

curl -I https://example.com

or
run https://securityheaders.com
→ This helps you verify if the headers survive the CDN.

What You Cannot Do Yourself (Adobe Required)

If you're using Adobe’s default CDN (Fastly) and:

• Headers are being stripped or blocked, even though cdn.yaml is correct

• You don't have a custom CDN (like Akamai) in front

• You've confirmed that AEM is setting headers properly (seen on publish-<env>)

Then it’s time to raise a ticket with Adobe Support.

They will:

• Check the Fastly edge configuration

• Help propagate the correct header policies

• Confirm if custom rules need to be whitelisted

Reference: https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/con...

[AmitVishwakarma]

Hi @EvertonSa2 ,

If headers work in publish-<env>.adobeaemcloud.com but not in your public PROD URL, the issue is ALWAYS in your CDN or WAF (e.g., Fastly, Akamai, CloudFront, Cloudflare).

Try below steps:

1. Test from curl (public domain)

Run:

curl -I https://your-production-domain.com

Check if headers like these appear:

  - Content-Security-Policy

  - X-Frame-Options

  - Strict-Transport-Security

  - X-Content-Type-Options

  - If they don’t => the CDN or WAF is stripping/blocking them.

2. Add Headers in cdn.yaml for Fastly (Adobe Default CDN)

If you’re using Adobe’s default Fastly CDN, do this:

ui.config/src/conf/cdn/cdn.yaml

rules:
  - path: "/*"
    headers:
      - name: "Content-Security-Policy"
        value: "default-src 'self'; script-src 'self' 'unsafe-inline'"
      - name: "X-Frame-Options"
        value: "SAMEORIGIN"
      - name: "X-Content-Type-Options"
        value: "nosniff"
      - name: "Strict-Transport-Security"
        value: "max-age=63072000; includeSubDomains; preload"

Commit this file, then deploy via Cloud Manager pipeline.

After deployment, wait a few minutes and re-test:

curl -I https://your-production-domain.com

The headers should now appear.

3. WAF/Custom CDN?

If your PROD domain uses a custom CDN (Akamai, Cloudflare, AWS CloudFront) or a WAF in front of Adobe’s CDN, then:

Those layers may strip security headers, even after AEM or Fastly sets them.

Ask your network/CDN team to:

  - Whitelist the headers

  - Pass all headers from origin

  - Avoid overriding or stripping the security-related headers

4. Ensure HTTPS is Enforced

If your PROD domain responds to HTTP and HTTPS:

  - Redirect HTTP → HTTPS using Fastly or Dispatcher

  - Security headers like Strict-Transport-Security will only be valid on HTTPS

6. Force HTTPS and Headers in Fastly (cdn.yaml)

rules:
  - path: "/*"
    cache:
      enabled: true
    redirect:
      to: "https://%{req.http.host}%{req.url}"
      status: 301
    headers:
      - name: "Strict-Transport-Security"
        value: "max-age=31536000; includeSubDomains; preload"
      - name: "Content-Security-Policy"
        value: "default-src 'self'"
      - name: "X-Frame-Options"
        value: "SAMEORIGIN"
      - name: "X-Content-Type-Options"
        value: "nosniff"

Regards,
Amit

[EvertonSa2]

Hello

I tested it using curl curl -I https://your-production-domain.com
But PowerShell returns the information "Invoke-WebRequest cmdlet at command position 1 of the pipeline. Provide values ​​for the following parameters:
Uri: "
I add https://your-production-domain.com or http://your-production-domain.com and it returns the following message "curl: Unable to locate unit. There is no unit named 'https'.

But I just found out that we have an Akamai, so from what you mentioned it may be that Akamai is blocking the headers.
What I find strange is that in the link:
"https://your-production-domain.com" the headers appear correctly, but in the link "http://your-production-domain.com" no headers appear.
Is it possible for Akamai to block http headers, but leave them free for https?

[AmitVishwakarma]

Hi @EvertonSa2 ,

HTTPS vs HTTP Behavior

Security headers like Strict-Transport-Security, Content-Security-Policy, etc. are only valid over HTTPS.

When you access http://your-production-domain.com, Akamai might not redirect to HTTPS, or it may strip the headers from the response.

Most security headers are ignored or invalid over HTTP, so Akamai/CDNs often don’t apply them there.

Akamai Can Handle HTTPS and HTTP Differently?

Yes, Akamai can apply different rules for http:// and https://.

Example: Akamai’s Edge Config may strip headers on http traffic to avoid caching or duplicating headers.

Regards,
Amit

[EvertonSa2]

I asked the Akamai team if they are blocking HTTP headers, they analyzed it and informed me that they are not blocking them.

This is strange because my http://publish- <env>.adobeaemcloud.com link in stage and dev returns the headers ok, but the https://publish- <env>.adobeaemcloud.com link in prod does not show the headers.

Is there any documentation from Adobe stating that it is not possible to implement headers in HTTP? Because if there is such documentation, I would like to have it to present to the security team to clarify that I can't do anything else about this issue, thus being able to close the subject of this vulnerability of headers in HTTP.