Controls whether your site can be displayed inside an iframe to prevent clickjacking attacks.

Specifies which origins are allowed to access your site’s resources via cross-origin requests.

Forces browsers to use HTTPS only, protecting against protocol downgrade and cookie hijacking attacks.

Restricts which origins can load your site's resources (e.g., images, scripts) to prevent data leaks.

Requires all embedded resources to explicitly grant permission, enabling secure cross-origin isolation.

Controls how much referrer information (URL details) the browser sends when navigating away from your site.

Allows or denies access to powerful browser features (e.g., camera, geolocation, microphone).

Prevents browsers from MIME-type sniffing by enforcing the declared content type (reducing script injection risks).

Defines allowed sources for content (scripts, images, styles) to mitigate XSS, data injection, and related attacks.

Isolates your browsing context from cross-origin pages to protect against certain cross-origin side-channel attacks (e.g., Spectre-like attacks) and cross-window interference.

The application for which the security header change took place.

The URL of the web page on which the security header change was detected.

The type of header affected in the change. For descriptions on each security header, please refer to Security header categories.

The date and time of the most recent activity relating to the tracked incident.

The header value prior to security header change

For example, if the header value changed from AAA to BBB, then the From value would be AAA.

The header value prior after the security header change.

For example, if the header value changed from AAA to BBB, then the To value would be BBB.

If the header was removed in the change, the To value would be [Removed].

The Risk indicates the likelihood that a security header change event poses a security concern.

• Very Low

• Low

• Medium

• High

• Very High

Indicates whether the header change incident has been reviewed for PCI DSS 4.0 compliance. Click the edit icon under Action to complete the review.

Under PCI DSS 4.0, each JavaScript file and security header configuration on the payment page must include a Justification. The justification demonstrates that the item is intentionally allowed, necessary for business or technical operations, and has been evaluated for risk. This information is used as evidence for internal security teams and QSA auditors.

A complete Justification must include:

• Purpose: Why the script or header is needed.

• Risk Evaluation: Any associated risks and why those risks are acceptable.

• Mitigation: Controls that manage or reduce risk (for example, CSP, SRI, or monitoring).

When writing justifications, include the following elements. These do not need to be long, but the information must be complete:

• Business Purpose: What business need does the script or header address?

• Data/Risk Impact: Does it interact with payment forms or potentially access sensitive data such as PAN, CVV, or cardholder information?

• Controls/Mitigations: What protections are in place (for example, version locking, domain allowlists, integrity checks, monitoring)?

• Scope & Ownership: Which URLs does it apply to, and which team is responsible?

• Exception/Timeline (if applicable): If this is a required relaxation, is it temporary or long-term? What is the remediation plan and timeline?

Sample justification for a CAPTCHA script on a checkout page： Used to provide bot protection and prevent automated card-testing attacks on the payment form. The acquiring bank requires CAPTCHA as part of its fraud prevention controls.