Introduction

Modern browsers rely on HTTP response headers to enforce important security boundaries.
The most relevant one is the Content Security Policy (CSP), which restricts the origins from which scripts, styles, images, fonts, and connections may be loaded, thereby mitigating cross-site scripting (XSS) and data injection attacks.
Additional headers such as X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and Cross-Origin-Opener-Policy further harden the browser environment.

This guide explains the headers in the Intershop PWA that are included by default, how the configuration mechanism works, and how projects can override, extend, or remove them.

Header Management Locations

The Intershop PWA manages security headers in the NGINX layer, not in the Angular application or the SSR Express server.
NGINX adds the configured headers to the main storefront location responses, including cached pages.
Some locations, for example, static assets and the sitemap, are served without them.

Shipped Default Headers

The standard PWA ships a secure-by-default, yet deliberately permissive, baseline in additional-headers.yaml.

Rationale for the Permissive Defaults

The default policy intentionally allows https: sources so that a typical storefront using third-party analytics, payment providers, or a CDN keeps working out of the box, while vulnerability scanners still see the required headers.

• 'unsafe-inline' is kept for script-src and style-src because the PWA and common integrations (e.g., tag managers) rely on inline scripts and styles.
• 'unsafe-eval' is not included, because production builds do not require it.
• Clickjacking protection (frame-ancestors / X-Frame-Options) is deliberately left off so that the PWA can still be embedded in the ICM Design Preview and the IAP Design View.
• Cross-Origin-Opener-Policy uses same-origin-allow-popups so popup-based checkout and payment flows are not broken.

The First Step Against XSS: Adjust script-src

The shipped default keeps 'unsafe-inline' only so that storefronts and integrations that still rely on inline scripts do not break out of the box.
Once your project no longer depends on inline scripts, drop 'unsafe-inline' and the broad https: source from script-src:

# permissive default (inline XSS NOT blocked; external scripts from ANY HTTPS host allowed)
script-src 'self' 'unsafe-inline' https:;

# hardened (inline XSS blocked; only same-origin scripts allowed)
script-src 'self';

Allow specific third-party scripts by adding their explicit origins (see Common Third-Party Scenarios) or a per-request nonce/hash — but never by re-adding 'unsafe-inline' or a bare https:.

Header Configuration

There are two ways to provide the header source:

• At build time: edit additional-headers.yaml. The values are built into the custom NGINX image, so no runtime variable is needed.
• At runtime: set the ADDITIONAL_HEADERS environment variable (or ADDITIONAL_HEADERS_SOURCE for an external gomplate datasource).

The YAML format is a list of single-key entries under headers::

headers:
  - Header-Name: 'header value'
  - Another-Header: 'another value'

Source Resolution and Precedence

At container start, nginx/docker-entrypoint.d/40-gomplate.sh resolves the header source in the following order:

1. ADDITIONAL_HEADERS_SOURCE if set (an explicit gomplate datasource URI), otherwise
2. ADDITIONAL_HEADERS if set, the runtime value is used and the shipped file is ignored entirely, otherwise
3. the built-in additional-headers.yaml`_ file.

Whole-Source Replacement, Not Merge

Setting ADDITIONAL_HEADERS replaces the complete header list; it does not merge with the shipped defaults.
Whatever source wins provides the full set of headers that NGINX emits.
There is no per-header override, which has direct consequences for the three use cases below.

Configuration Use Cases

Because the source is replaced as a whole, overriding or extending headers means providing the full desired list, not just the delta.

1. Override Certain Values

To change one or more values (for example, to lock the CSP down to your known ICM host and payment provider), copy the full list and adjust the entries as needed.

docker-compose example:

nginx:
  environment:
    ADDITIONAL_HEADERS: |
      headers:
        - Content-Security-Policy: "default-src 'self' https://your-icm-host; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' https://www.google-analytics.com; frame-src 'self' https://secure.pay1.de; base-uri 'self'; object-src 'none'; frame-ancestors 'self' https://your-icm-host;"
        - X-Content-Type-Options: 'nosniff'
        - Referrer-Policy: 'strict-origin-when-cross-origin'
        - Permissions-Policy: 'camera=(), microphone=(), geolocation=(self)'
        - Cross-Origin-Opener-Policy: 'same-origin-allow-popups'

PWA Helm Chart example (use cache.additionalHeaders with the same content):

cache:
  additionalHeaders: |
    headers:
      - Content-Security-Policy: "default-src 'self' https://your-icm-host; style-src 'self' 'unsafe-inline'; font-src 'self' data:; object-src 'none';"
      - X-Content-Type-Options: 'nosniff'

2. Add Configuration

To add an extra header or additional trusted origins, provide the defaults plus your additions as a complete list.

nginx:
  environment:
    ADDITIONAL_HEADERS: |
      headers:
        # keep the defaults you still want ...
        - Content-Security-Policy: "default-src 'self' https:; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline' https:; img-src 'self' data: blob: https:; font-src 'self' data: https:; connect-src 'self' https:; frame-src 'self' https:; child-src 'self' blob: https:; worker-src 'self' blob:; form-action 'self' https:; base-uri 'self'; object-src 'none';"
        - X-Content-Type-Options: 'nosniff'
        - Referrer-Policy: 'strict-origin-when-cross-origin'
        - Permissions-Policy: 'camera=(), microphone=(), geolocation=(self)'
        - Cross-Origin-Opener-Policy: 'same-origin-allow-popups'
        # ... and add the new headers
        - Strict-Transport-Security: 'max-age=63072000; includeSubDomains; preload'
        - X-Frame-Options: 'SAMEORIGIN'

3. Remove All Headers

Provide a source that contains a valid but empty headers: list so that NGINX emits no add_header directives.
This is not the same as leaving ADDITIONAL_HEADERS empty (''): an empty string counts as "not set" and falls back to the shipped defaults, whereas the value below is real YAML content that just defines zero entries.

nginx:
  environment:
    ADDITIONAL_HEADERS: |
      headers:

For a permanent, image-level removal, reduce additional-headers.yaml to a single headers: line.

Common Third-Party Scenarios

When extending the PWA, identify all origins a resource loads from (using browser dev tools or the vendor documentation) and add them to the matching directives.

Example CSP fragment that adds Google Tag Manager to a locked-down policy:

Content-Security-Policy: "default-src 'self'; script-src 'self' https://www.googletagmanager.com; connect-src 'self' https://www.google-analytics.com https://analytics.google.com; img-src 'self' data: https://www.google-analytics.com; style-src 'self' 'unsafe-inline'; font-src 'self' https://fonts.gstatic.com;"

Hardening for PCI DSS 4.0

The permissive defaults avoid breaking storefronts; they are not a PCI DSS 4.0-compliant policy.
When hardening the shipped baseline for payment pages, re-enable the clickjacking protection the default deliberately omits by adding frame-ancestors (and optionally X-Frame-Options: SAMEORIGIN) once Design Preview / IAP embedding is no longer required.

The remaining measures (i.e., authorizing every script (Requirement 6.4.3), removing 'unsafe-inline', avoiding wildcard origins, applying Subresource Integrity (SRI), and maintaining a script inventory) are covered in the Security Standard PCI DSS 4.0 guide.

Further References

• Building and Running NGINX Docker Image
• Security Standard PCI DSS 4.0
• MDN: Content-Security-Policy
• gomplate datasources