PCI DSS Requirement 6.4.3 Explained for Online Stores

PCI DSS Requirement 6.4.3 addresses the scripts that run in a customer’s browser on a payment page. Where 6.4.3 applies to your assessment, you need to authorize those scripts, protect their integrity, and maintain an inventory explaining why each is necessary. A familiar vendor name or a working checkout does not establish that a script is safe.

Before choosing controls, identify your payment integration and compliance validation route. A store that builds its own payment page has different responsibilities from one using a provider’s embedded form or redirecting customers to a hosted checkout. The SAQ A script-security eligibility criterion makes that distinction especially important.

This guide explains the browser-security principles for US and UK online stores. Your checkout architecture and the organization accepting your compliance submission determine how those principles apply to your assessment.

Check the SAQ A distinction · Copy a script review record

Why payment-page scripts need their own controls

A checkout page can load code from your application, payment provider, tag manager, analytics services, and other integrations. Some scripts load additional scripts after the page opens. The browser therefore executes more than the code stored in your website’s main repository.

E-skimming targets that browser environment to steal payment information. A store can have an encrypted connection and still deliver malicious code to customers. HTTPS protects the connection; it does not decide whether a script should be running on the page.

PCI SSC’s explanation of its payment-page security guidance connects Requirements 6.4.3 and 11.6.1 to script authorization, integrity, tamper monitoring, and security-impacting HTTP headers. These controls address what reaches the customer’s browser, not just the condition of your server.

Translate 6.4.3 into three management questions

The following is a plain-English summary. Use the full requirement and its testing procedures in the PCI SSC Document Library when preparing your assessment.

1. Has this script been authorized?

There should be a method for confirming that each script is authorized. In practice, make it possible to connect a script observed in the browser to an approval decision. Record who approved it, where it is allowed to run, and which change introduced it.

A tag manager deserves particular attention. Approving the container does not, by itself, explain every script that people can publish through it. Restrict publishing access and include checkout-related tag changes in your approval process.

2. How is its integrity protected?

Authorization and integrity answer different questions. Authorization concerns permission to run. Integrity concerns whether the script remains as intended rather than being altered without authorization.

Your technical approach must fit the scripts and integration you actually use. A static file controlled by your developers and a frequently changing provider script may require different treatment. Document what each control protects and where it has limitations.

3. Why is it necessary on the payment page?

The inventory should identify the scripts and include a written business or technical justification for each. A list of domains alone provides little explanation of what is executing or why it belongs on checkout.

For example, “creates the payment token for the selected payment method” is a useful explanation. “Marketing requested it” needs more detail. Ask whether the same business purpose could be served on a page that does not handle payment entry.

Embedded forms and redirects are different SAQ A situations

PCI SSC’s SAQ A script-eligibility FAQ explains that the relevant criterion applies when the merchant’s webpage embeds a payment provider’s page or form, such as an iframe.

The FAQ describes two routes: implement protective techniques, potentially including those in 6.4.3 and 11.6.1, or obtain confirmation from the compliant payment provider that its embedded solution protects the merchant’s payment page against script attacks when implemented as instructed.

SAQ A r1 removed the standalone 6.4.3 and 11.6.1 assessment requirements and replaced them with this eligibility confirmation. That change does not remove those requirements from the full PCI DSS standard or other applicable assessment routes. Redirects and fully outsourced payment-link arrangements are excluded from this particular criterion. Other SAQ eligibility conditions still apply. Confirm the appropriate questionnaire with the organization accepting your compliance submission, typically your acquirer or payment brand.

If you rely on provider confirmation, retain the confirmation for your actual integration and the instructions it depends on. A general statement that a provider is PCI DSS compliant does not explain whether your implementation meets this particular condition.

Build an inventory from the checkout customers actually use

Start with a developer-assisted walkthrough of your authorized checkout environment. Inspect scripts loaded during the payment journey and compare them with your approved integrations. Use test transactions and avoid retaining real payment information in screenshots or browser exports.

As a practical coverage check, include guest and signed-in checkout, relevant consent choices, different payment methods, and alternate checkout routes. Scripts that appear only after an interaction can be missed by inspecting the initial page source.

The following hypothetical inventory illustrates useful management fields. It is not a prescribed PCI SSC template.

Checkout flow / page / environment:
Validation route and responsible owner:
Script identity, source and relevant revision:
Loader or tag-manager dependency:
Observed browser state / observation date / evidence reference:
Authorization decision / approver / date:
Business or technical necessity:
Integrity method and supporting evidence:
Applicable provider instructions or confirmation:
Exception / responsible owner / resolution date:
Related change-monitoring record, where applicable:
Next review trigger / reviewer / unresolved question:

Removing unnecessary scripts reduces the number of components you must understand and maintain. Test the complete checkout after removal; a component that looks cosmetic may have an unexpected dependency.

CSP and integrity checks are tools, not automatic compliance

Content Security Policy (CSP) gives browsers rules about which resources may load or execute. It can support a controlled script environment, but allowing a trusted domain does not prove that every script delivered by that domain is unchanged or appropriate.

Do not confuse testing a policy with enforcing it. As Mozilla’s CSP documentation explains, a report-only policy generates reports without enforcing that policy. Report-only deployment can help identify checkout breakage before enforcement; it is not itself a blocking control.

Subresource Integrity (SRI) lets the browser compare a supported resource against an expected cryptographic hash. It can be useful for suitable external scripts, but changing the file changes its hash. Coordinate legitimate updates and follow the payment provider’s integration requirements rather than adding controls blindly.

Our comparison of WAF, RASP, and CSP provides background on where these controls operate. For this requirement, the practical question is whether your chosen combination addresses payment-page scripts and produces evidence you can explain.

Understand the separate role of Requirement 11.6.1

Requirement 6.4.3 concerns script management. Requirement 11.6.1 addresses detecting unauthorized changes to payment pages and relevant HTTP headers as received by the browser. An approval record cannot tell you that a page was later altered; a change alert cannot supply the missing business justification for a script.

Keep those responsibilities distinct when evaluating a service. Ask what it observes, which checkout states it covers, what triggers an alert, who receives it, and how investigations are recorded. Confirm the applicable monitoring frequency against the full requirement and your assessment approach rather than assuming an annual review is sufficient.

Handle 3-D Secure scripts carefully

PCI SSC provides a specific clarification for 3-D Secure (3DS). Its FAQ on 3DS scripts and 6.4.3 states that validation against 6.4.3 is not required for scripts performing 3DS functionality because of the established trust relationship with the 3DS provider. Scripts running for other purposes remain subject to 6.4.3.

Do not extend that clarification to every script supplied by a payment company. Identify the function of the particular script before deciding how the clarification applies.

Make the next decision about ownership

PCI SSC identified March 31, 2025 as the effective date for these previously future-dated requirements in its e-commerce security announcement. Treat implementation as an ongoing responsibility, with your current validation route determining what you must demonstrate.

Bring your developer and payment provider a description of the checkout flow, the scripts you have observed, and the questionnaire your acquirer expects. Establish who authorizes changes, who operates integrity controls, and who investigates alerts.

If the payment integration or responsibility boundary remains unclear, that is a concrete reason to involve a Qualified Security Assessor before signing a compliance declaration. The useful outcome is a checkout whose scripts have an explainable purpose, an accountable approval decision, and appropriate technical protection—with evidence that remains accurate when the checkout changes.

Technical guidance updated: 2026-10-13. Clarified when 6.4.3 applies and distinguished SAQ A r1 eligibility from the full PCI DSS requirements.

SAQ A source link and worksheet review: October 23, 2026. Connected the eligibility reference directly to PCI SSC FAQ 1588 and added a blank script review record. The illustration is explanatory; it does not establish that a page is PCI DSS compliant. No checkout implementation was assessed for this revision.