Key takeaways

  • PCI DSS 4.0.1 requirement 6.4.3 asks that every script loaded and executed in the consumer's browser on a payment page is authorized, has its integrity assured, and is listed in an inventory with a written justification.
  • Requirement 11.6.1 adds change and tamper detection for payment page content and HTTP headers. Both became mandatory on March 31, 2025.
  • A Content Security Policy (CSP) is an HTTP header that tells the browser which sources may load scripts. It is the enforcement half of an allow-list.
  • Subresource Integrity (SRI) adds a cryptographic hash to a script tag so the browser refuses a file that changed. It suits scripts you host or that rarely change, not vendor scripts that update without notice.
  • Neither one is a complete answer: you still need the inventory, the justification and a way to detect changes, which is what assessors will ask to see.
  • Merchants that redirect to or embed a payment provider's page have different obligations; check your Self-Assessment Questionnaire with your acquirer.

Why payment pages are a target

A checkout page is ordinary web code plus a number of scripts from other companies: analytics, chat, tag managers, fonts, fraud tools. If an attacker changes any one of them, or the account that hosts it, the new code runs inside your customer's browser with access to what they type. This is how web skimming attacks work. The card data never touches your server, and you may not see anything wrong. Our article on SAQ A and SAQ A-EP covers which questionnaire applies to different page designs. This one covers the script controls.

What PCI DSS 4.0.1 asks

Requirement 6.4.3 applies to the scripts on payment pages that are loaded and executed in the consumer's browser. It asks for three things: a method to confirm each script is authorized, a method to assure the integrity of each script, and an inventory of all scripts with a written business or technical justification for each. Requirement 11.6.1 asks for a mechanism that alerts on unauthorized changes to the HTTP headers and the contents of payment pages as received by the consumer's browser, checked at least weekly or at a frequency set by a targeted risk analysis. Both were future-dated in PCI DSS 4.0 and became required on March 31, 2025.

Which of these apply to you depends on how your payment page is built and which SAQ your acquirer requires. The PCI Security Standards Council has published guidance on the script requirements for the simplest e-commerce designs. Read it with your acquirer, because the council does not decide who must validate.

Content Security Policy in plain terms

A CSP is a response header, Content-Security-Policy, that lists where the browser may load resources from. The key directive for this problem is script-src, which names the origins, hashes or nonces of scripts the page may run. Anything else is blocked and can be reported. The specification is W3C Content Security Policy Level 3.

  • script-src with a short list of origins is easy to write but weak if an allowed origin hosts user content or an open redirect.
  • Nonces: a random value generated for each response and added to approved script tags. Good for pages rendered on a server.
  • Hashes: a digest of an exact inline script. Works for fixed inline code.
  • strict-dynamic: lets a trusted script load others, which helps with tag managers but widens trust.
  • Avoid unsafe-inline and unsafe-eval on payment pages. They defeat the purpose.
  • report-to or report-uri: where the browser sends violation reports.

Start with Content-Security-Policy-Report-Only. The browser reports what would have been blocked, without breaking the page. Tune the policy until reports show only real problems, then switch to enforcement.

Subresource Integrity in plain terms

SRI is defined by the W3C. You add an integrity attribute with a hash, such as sha384 followed by the base64 digest, to a script or link tag. The browser downloads the file, computes the hash and runs it only if it matches. For cross-origin files the server must allow it with CORS, and the tag needs crossorigin set, usually to anonymous.

SRI is strong where the file does not change: a library version you pin, a script you host yourself. It is the wrong tool for a vendor script that the vendor edits at the same URL, because the hash will then fail and the page will break, or the team will remove the integrity check to make it work. For those, rely on a vendor you have vetted, host a reviewed copy yourself, or choose a design where the payment fields live on the provider's page.

How they map to 6.4.3 and 11.6.1

  • Authorized: a CSP allow-list plus a change process that records who approved each script and why.
  • Integrity assured: SRI hashes for static scripts, a hosted and reviewed copy for others, and CSP nonces or hashes for inline code.
  • Inventory and justification: a maintained list, not something the browser produces. Your tag manager and a periodic crawl of the payment page can feed it.
  • Tamper detection: CSP violation reports, plus a scheduled check that fetches the page as a browser does and compares scripts and headers to the baseline.

Assessors look for evidence that this runs continuously: the policy in place, the inventory current, the alerts reviewed. A header set once and never checked does not meet the intent.

A practical rollout

  • Map your payment pages and the scripts each one loads, including scripts loaded by other scripts.
  • Remove what you do not need. Every script you drop is one less to justify.
  • Write the inventory with an owner and a reason for each script.
  • Deploy CSP in report-only, review reports for a few weeks, then enforce.
  • Add SRI to static third-party and first-party files.
  • Set up a scheduled page check and alerting, and review the alerts.
  • Run the check again after every release or tag change.

Limits to know

  • CSP is enforced only by browsers that support it, and a mistake in the policy can silently allow what you meant to block.
  • It does not stop a script you allowed from behaving badly. That is the point of the inventory and the vendor review.
  • A compromised server can change the CSP header itself. Tamper detection outside the server is why 11.6.1 exists.

If you want a payment page reviewed, with the script inventory built and CSP and SRI deployed, ask about our Cybersecurity service. We assess authorized pages only. This article is general information and is not a PCI DSS assessment.

Sources

This article is general information, not legal, contracting or technical advice for your environment. Which PCI DSS requirements apply to you is decided with your acquiring bank and a qualified assessor. Last reviewed .

Next article

Related reading

Need help with this?

We find out whether everything you run is safe from attackers, then we fix it.

Cybersecurity