Magento Open Source payment page scripts for PCI DSS 6.4.3 and 11.6.1

Requirement 6.4.3 asks for three things, and an assessor will look for evidence of each. First, a method to confirm that each script on a payment page is authorized. Second, a method to assure the integrity of each script, so that a script changed after approval can be detected. Third, an inventory of every script on the payment pages, with a written justification for each one. PCI DSS v4.x made this requirement mandatory on 31 March 2025, and it applies to merchants validating with SAQ D. Magento Open Source provides technical controls that help with the first two elements, but the inventory and the justification records are work your team must produce and keep current.

Magento Open Source supports Content Security Policy headers from version 2.3.5, and from 2.4.7 CSP runs in restrict mode by default on storefront and admin payment pages. Restrict mode enforces a policy list: the browser loads only the sources and scripts the list allows. That covers authorization for the entries on the list, but it does not explain them. The policy does not record who requested an entry, what business purpose it serves, who approved it, or when it was last reviewed. Before go-live, export the active policy, reconcile every entry against your page-level inventory, and keep the justification in a register owned by a named person, outside the Magento configuration itself.

PCI SSC FAQ 1581 narrows scope for one category of script. A merchant that uses a 3-D Secure solution does not need to validate 6.4.3 for the 3DS scripts. Any script that runs for another purpose stays subject to 6.4.3. In practice, this means the inventory must sort scripts by purpose, not by origin. The 3DS provider's challenge scripts can be documented as excluded, while analytics tags, chat widgets, marketing pixels, A/B testing libraries and session replay tools remain in scope even if they load on the same checkout page. Ask the 3DS provider in writing which scripts it loads, and confirm that no other script is bundled into the same file or tag manager container.

Plan the work with the people who will sign the evidence. Your Qualified Security Assessor or internal assessor should confirm whether the 3DS scope decision is acceptable under your validation type, and the 3DS provider should supply its script documentation before the inventory is closed. Your Magento developers should be able to show which theme, extension or tag manager adds each script. Remember that the PCI SSC does not enforce compliance; the payment brands decide which entities must validate and run their own programs. Keep the inventory, the justifications, the scope decision and the review dates together so that the evidence can be produced at assessment time.

Requirement 11.6.1 asks for a change- and tamper-detection mechanism that alerts personnel to unauthorized modifications of security-impacting HTTP headers and payment page contents as received by the consumer browser. It must run at least once every seven days, or at a frequency set by a targeted risk analysis under 12.3.1. The requirement is about noticing change and telling people. Magento's restrict-mode Content Security Policy (CSP) and Subresource Integrity (SRI) controls do something different: they limit what the browser will execute. Adobe's developer documentation says Magento Open Source supports CSP headers from version 2.3.5, and from 2.4.7 CSP runs in restrict mode by default on storefront and admin payment pages. Confirm in your own environment and Magento version that restrict mode is active on the checkout and payment pages you serve, and that no custom configuration has weakened the policy.

A CSP header tells the browser which origins may supply scripts, styles, frames and other resources. In restrict mode, a script that is not on the allowed list is blocked from running, and the browser reports the violation. A violation therefore looks like a blocked resource and a report event, not a silently altered checkout. That is why restrict mode is a prevention layer. It stops an injected or swapped script from executing on the payment page, but it does not, on its own, produce the inventory of what changed, the alert to personnel, or the record of the 11.6.1 check. A header that is itself altered by an attacker, or a policy that is too broad, can allow the malicious script through, so the policy must be reviewed as a security artifact.

Subresource Integrity adds a second check: a script tag carries a cryptographic hash, and the browser refuses to run the file if its contents no longer match. SRI works well for scripts loaded from a fixed URL, such as a third-party payment or fraud script, but it does not cover inline scripts or scripts that change on every build unless the hashes are regenerated with each deployment. Confirm whether SRI hashes are generated for your payment page scripts, whether the build or deployment process produces them, and whether the browser enforces them in production. A missing or stale hash is a common reason a legitimate script is blocked, so the team that owns deployments needs a documented path for updating hashes.

The gap that remains is detection in the sense 11.6.1 means. You need a mechanism that observes the headers and page content as a consumer browser receives them, compares them against a known baseline, and alerts a named role. CSP violation reports can feed that signal if they are sent to a collector that someone monitors. Confirm whether your violation reports go to a collector, who receives the alert, how quickly it is triaged, and whether the collector is itself protected. Browser-side tests or an external monitoring service can supply the received-content view, and their schedule must meet the seven-day ceiling or a documented risk-based frequency.

Practical decisions follow from this split. Decide which CSP directives and report endpoints you will own, who reviews policy changes, how SRI hashes are produced and rotated, and which tool produces the weekly-or-better comparison of received headers and page content. Record the outcome as evidence for both 6.4.3 and 11.6.1. Prevention limits harm, and detection proves the controls are still working. Neither replaces the other, and neither is a substitute for a qualified assessor's review of your scope.

Requirement 11.6.1 sets the cadence for this mechanism. It must run at least once every seven days, unless a targeted risk analysis performed under requirement 12.3.1 sets a different frequency. The seven-day requirement became mandatory on 31 March 2025, so a store validating against PCI DSS v4.0.1 should already have a scheduled job or monitoring service in place. The first decision is whether to keep the weekly default or to document a risk-based interval. A longer interval needs a written analysis that considers how often Magento core, theme and extension code changes, how quickly your team can review alerts, and how much the payment page relies on third-party scripts. Most stores will find the weekly schedule easier to defend, and the analysis must be reviewed when the payment flow or script set changes.

Each run compares what a consumer browser receives with an approved baseline. The baseline covers the security-impacting HTTP headers on storefront payment pages, including the Content Security Policy headers that Magento Open Source supports from 2.3.5 and that run in restrict mode by default from 2.4.7. It also covers the contents of those pages, such as script tags and their integrity attributes. The check should request pages the way a shopper's browser would, with the same headers, cookies and redirects, because server-side file hashes can miss what is injected at the edge or by a tag manager. Confirm with your tool vendor how it handles fields that change per session, such as form tokens and cart identifiers, so routine variation does not hide genuine changes. Also confirm where the baseline is stored and who can write to it.

The baseline changes whenever the store changes legitimately, so re-approval needs a defined path. Each Magento upgrade, patch, theme change or extension update should produce an expected difference tied to a change ticket. The owner of the payment page scripts reviews that difference against the script inventory required by requirement 6.4.3, confirms that each new or altered script is authorized and justified, and then approves a new baseline with a named approver and date. Adobe's release schedule says full patches for the 2.4.x LTS line ship annually in May and that security patches ship at least annually for all supported release lines. Its upgrade guide recommends applying each patch cycle to stay secure and PCI compliant. Because security patches and extension updates can land separately, plan approval windows around them. The job that detects changes should not also update the baseline automatically.

Alerts need an owner and a record. When a run finds an unapproved header or script change, the alert should reach a named on-call role through a channel someone actively watches, such as a paging service, and include the diff, the detection time and the affected page. Personnel then triage the change, decide whether it is malicious, an unapproved release or a fault, and take containment steps such as removing the script or restoring the baseline. Each step goes into a response record that links to the alert, the change ticket and the 6.4.3 justification for any script involved. Ask your QSA or acquirer which evidence they expect, such as sample alerts, closed tickets or run logs. PCI SSC FAQ 1220 states that certificates are not recognized as validation, so the assessment is documented on the Report on Compliance or the Self-Assessment Questionnaire and its Attestation of Compliance.