PCI 6.4.3 and 11.6.1: how do you stop e-skimming this holiday season?

What is e-skimming (web skimming), and why does it matter during the holidays?

E-skimming, also called web skimming, is the theft of card numbers from a website's checkout by a malicious script running in the customer's browser. The payment still goes through, the customer sees nothing unusual, and the card data is quietly copied to the attacker. The PCI Security Standards Council puts it directly: "Scripts running in consumers' browsers are now a significant target for attackers seeking to steal payment card data." PCI DSS requirements 6.4.3 and 11.6.1 exist to stop it.

The holiday season raises the stakes for any organization that takes cards online. Year-end giving campaigns, event registrations, client portal payments and seasonal promotions all bring more transactions through the same pages. They also bring more changes to those pages: new donation forms, marketing tags, chat widgets and analytics scripts added in a hurry. Every new script is code your organization did not write, running on the page where card numbers are typed.

What do PCI 6.4.3 and 11.6.1 require for payment page scripts?

Script control and tamper detection, both mandatory since March 31, 2025. Requirement 6.4.3 says all payment page scripts loaded and executed in the consumer's browser must be managed so that:

• A method confirms that each script is authorized.
• A method assures the integrity of each script.
• An inventory of all scripts is maintained, with written justification for why each is necessary.

The requirement covers scripts from your own environment and scripts loaded from third and fourth parties. That last group matters: a marketing tag you approved can load other scripts you never saw.

Requirement 11.6.1 adds detection. It calls for a change- and tamper-detection mechanism that alerts personnel to unauthorized modification of the HTTP headers and the contents of payment pages "as received by the consumer browser." The check must run at least once every seven days, or at a frequency set by a targeted risk analysis under requirement 12.3.1.

Do these requirements apply to a nonprofit, law firm or practice that uses a payment processor?

It depends on how the payment page is built, which is the same question that decides your Self-Assessment Questionnaire. Our guide to choosing the right PCI SAQ walks through the options in detail.

• If your site fully redirects customers to the processor's own hosted page, the payment page itself belongs to the processor, though the page that sends customers there still needs protecting.
• If your site embeds the processor's payment form in an iframe and you validate with SAQ A, 6.4.3 and 11.6.1 are no longer listed as SAQ A requirements. PCI SSC replaced them in January 2025 with an eligibility criterion: the merchant must confirm its site is "not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)."
• If your own page controls how card data reaches the processor, you are typically outside SAQ A, and the full requirements apply.

The SAQ A criterion does not make scripts somebody else's problem. PCI SSC's FAQ 1588 explains that an embedded-form merchant can meet it in one of two ways: apply techniques such as those in 6.4.3 and 11.6.1 to its own page, or obtain written confirmation from a PCI DSS compliant processor that its embedded solution, implemented according to the processor's instructions, includes protection against script attacks. Either way, someone has to own the answer and keep evidence of it. Your acquirer or processor decides which SAQ you use, so confirm the choice with them.

How do you prevent web skimming on a payment page?

Use four layers: know every script, control what may load, watch for change, and limit who can edit the page.

• Script inventory: list every script on each payment and donation page, where it loads from, who requested it and why it is needed. Remove anything nobody can justify.
• Authorization and integrity: a Content Security Policy that allows scripts only from approved sources, and Subresource Integrity hashes on static third-party scripts so a modified file will not run.
• Change detection: a monitoring service or tool that loads the payment page as a browser would, compares scripts and security-related HTTP headers to an approved baseline, and alerts a named person when something changes.
• Access control: MFA on the website content management system, the hosting account and the tag manager, and a short list of people allowed to publish changes to payment pages.

Tag managers deserve particular attention. They make it easy for marketing staff to add scripts without a developer, which is useful most of the year and risky on the page that handles cards. Keeping tag managers off payment pages entirely is the simplest control.

What should you do before the holiday rush?

Set a short change freeze on payment pages and confirm your evidence now, while traffic is still normal.

• Confirm with your processor or acquirer which SAQ you validate with, and how your payment page is built.
• If you use SAQ A with an embedded form, get the processor's written confirmation of script protection, or document your own 6.4.3 and 11.6.1 techniques.
• Inventory every script on payment and donation pages, with a written reason for each, and remove the rest.
• Turn on change and tamper alerts that run at least weekly, and name the person who responds.
• Require MFA for everyone who can edit the website, hosting account or tag manager.
• Agree on a freeze window for payment page changes through year-end, with an exception process for urgent fixes.
• Review our notes on card testing and donation page security, the other common holiday attack on online payment forms.

What happens if a skimming script is found?

Treat it as a suspected compromise of account data and follow your incident response plan. Remove the script, preserve logs and copies of the affected page for investigation, and contact your acquirer or processor promptly, since card brand rules set out what happens next. Bring in outside counsel to assess breach notification duties under California law and any other states where affected customers live. A current script inventory and weekly change alerts shorten the time a malicious script can run unnoticed.

How does s90 help?

s90 offers PCI DSS support as a standalone add-on for organizations in Los Angeles and Orange County that take cards online. We help confirm the right SAQ with your processor, build the payment page script inventory, set up change and tamper monitoring, and keep the evidence ready for your annual validation. If you would like a second look at your payment pages before the holiday rush, we are glad to help.