Skip to main content
PCI Monitor

Security Library

Threats

How attackers steal card data in the browser, and what real cases show.

What Is Web Skimming? Magecart and Formjacking

Web skimming (Magecart, formjacking, e-skimming) hides JavaScript on checkout pages that copies card data as customers type. How it works.

Web skimming is the theft of payment card data by malicious JavaScript that runs inside a shopper's browser on a checkout or payment page. The script copies what the customer types and sends it to the attacker, while the real payment still goes through, so nobody notices. It is also called e-skimming, formjacking, or Magecart-style attacks, and it is the threat that PCI DSS requirements 6.4.3 and 11.6.1 were written to address.

Key takeaways

  • Web skimming is malicious JavaScript on a checkout page that copies card data in the browser; Magecart, e-skimming and formjacking are names for the same family of attacks.
  • The purchase still succeeds, which is why skimmers can run unnoticed for a long time.
  • HTTPS and server-side firewalls do not stop it, because the theft happens in the customer's browser.
  • Redirects and iframes reduce your exposure but do not remove the need to protect the page around them.
  • The practical defense is layered: fewer scripts, an inventory with approvals, a restrictive CSP, integrity checks, patching and change detection.

Frequently asked questions

What is web skimming?
Web skimming is the theft of payment card details by malicious JavaScript that runs on a checkout or payment page and copies the data customers type into the form. The attacker receives the data while the real payment continues normally.
Is Magecart a virus?
No. Magecart is not a single program or a single group. It is an umbrella name researchers use for many criminal groups and campaigns that inject card-stealing JavaScript into websites.
Does HTTPS protect against web skimming?
No. HTTPS protects data while it travels between the browser and your server. A skimmer reads the data inside the browser, before it is sent, so a valid certificate does not prevent it.
If I use a hosted payment page or iframe, can my site still be skimmed?
The risk is lower, but not zero. An attacker who controls the page around a redirect or an iframe may be able to replace the payment form or send customers elsewhere. PCI DSS 6.4.3 and 11.6.1 take this into account, and your acquirer or assessor decides how they apply to you.
How would I find out that my site has a skimmer?
Rarely by looking at the page. Organizations find skimmers through monitoring that compares the scripts and headers a browser receives with an approved baseline, through reports from card issuers or payment brands, or through security research. That is why change detection is part of the PCI DSS answer.

Read the full guide: What Is Web Skimming? Magecart and Formjacking8 min read

Third-Party JavaScript Risk: Supply Chain Attacks

Third-party scripts on payment pages (tag managers, analytics, chat widgets) are a supply chain risk. How compromises happen and how to manage them.

Every third-party script on a payment page runs with the same access as your own code: it can read the form, change the page and send data anywhere. If the company that serves that script is breached, sells its domain or simply ships a bad update, your customers' browsers run the attacker's code. This is a software supply chain risk, and it is the main way client-side card theft reaches well-defended merchants.

Key takeaways

  • A third-party script has the same power as your own code; the browser does not limit it to the tasks you had in mind.
  • Routes to compromise include a breached vendor, a changed or expired domain, chains of scripts that load other scripts, and content that varies by visitor.
  • The 2024 polyfill.io case showed that a trusted address can start serving harmful code without any change on the sites that use it.
  • Load fewer third-party scripts on payment pages, keep an inventory with approvals, and pin or restrict what remains.
  • Approval at the time of adding is not enough; monitor what is actually delivered.

Frequently asked questions

What is a JavaScript supply chain attack?
It is an attack in which the attacker compromises a script, library or service that many websites load, so that the malicious code reaches all of those sites at once without the attacker having to break into each one.
Does Subresource Integrity solve third-party script risk?
It helps with static files from a fixed address, because the browser blocks a file that no longer matches its hash. It cannot help with scripts that are generated per visitor or updated frequently, or with scripts loaded by other scripts. See the article on Subresource Integrity.
Is hosting a copy of the library myself safer?
It removes the risk that the vendor's server changes the file behind your back, but you become responsible for updating the copy and for any vulnerabilities in it. It works best together with an approval and update process.
Should payment pages load analytics and advertising scripts?
Each one widens the attack surface, and many organizations choose not to load them on the payment page. If you do, each needs a written reason, an approval and monitoring. PCI DSS 6.4.3 applies to every script on the payment page.

Read the full guide: Third-Party JavaScript Risk: Supply Chain Attacks7 min read

Client-Side Card Theft Incidents and Lessons Learned

What the British Airways, Ticketmaster and Newegg web skimming incidents of 2018 teach about third-party scripts, detection and regulators.

Three 2018 incidents, at British Airways, Ticketmaster UK and Newegg, show how card data is stolen from payment pages through injected or tampered JavaScript. In two of them the UK Information Commissioner's Office (ICO) later issued fines; in the third, outside researchers found the skimmer. This article sticks to what official decisions and the original researchers have published, and draws out the practical lessons.

Key takeaways

  • British Airways, Ticketmaster UK and Newegg (all 2018) show skimming through the site's own JavaScript, a third-party chatbot and a short injected script.
  • The ICO fined British Airways £20 million (16 October 2020) and Ticketmaster UK £1.25 million (13 November 2020).
  • Skimmers ran for weeks and were found by outside parties in several cases.
  • The practical lessons: monitor the page as the browser receives it, justify every script, restrict script sources and data destinations, and detect change quickly.

Frequently asked questions

How much was British Airways fined for its 2018 web skimming incident?
The ICO fined British Airways £20 million in a penalty notice dated 16 October 2020. The ICO had announced an intention to fine £183.39 million in July 2019; the final amount was lower after representations, mitigating factors and the effect of Covid-19 on the airline industry were considered.
What caused the Ticketmaster UK breach?
According to the ICO's findings, malicious code in a chatbot supplied by a third party and included on Ticketmaster's payment page captured customers' card details. The ICO fined Ticketmaster UK £1.25 million; Ticketmaster has disputed aspects of the decision.
How long did the Newegg skimmer run?
Researchers reported card details entered at checkout were exposed from 14 August to 18 September 2018, about five weeks. This comes from the researchers' analysis as reported in secondary coverage.
Did these incidents lead to PCI DSS 6.4.3 and 11.6.1?
The PCI SSC says the requirements aim to reduce e-skimming, which these incidents are examples of, but it does not name specific incidents as the cause. Treat them as background rather than as a documented reason.

Read the full guide: Client-Side Card Theft Incidents and Lessons Learned7 min read

XSS, DOM Tampering and Injected Skimmer Code

How attackers get malicious script onto a payment page: XSS, vulnerable plugins and libraries, stolen credentials and compromised third parties.

A skimmer has to get onto the payment page first. The usual ways are cross-site scripting (XSS) flaws, vulnerable plugins or libraries, stolen administrator or deployment credentials, and compromised third parties. Once a script runs on the page it can also tamper with the page's Document Object Model (DOM), for example by adding fields or replacing a payment form. Knowing the entry routes shows where to focus prevention and detection.

Key takeaways

  • XSS lets an attacker run script on your payment page without any access to your servers.
  • Other entry routes: vulnerable plugins and libraries, stolen credentials, compromised third parties and writable storage.
  • DOM tampering lets injected script add fields, overlay forms and copy data, even when your server's HTML is clean.
  • Combine safe coding, a strict Content Security Policy, patching, strong access control and monitoring of what browsers receive.

Frequently asked questions

What is the difference between XSS and a web skimmer?
XSS is a type of flaw that lets an attacker run script on a page. A skimmer is the malicious script itself, whose job is to copy card data. XSS is one way a skimmer can be delivered.
What is DOM tampering?
It is changing the live structure of a web page in the browser, for example adding form fields, overlaying a fake form or removing an element. Any script that runs on the page can do it.
Can a Content Security Policy stop XSS?
A well-built policy can block injected inline scripts and scripts from unapproved sources, which makes many XSS attacks fail. It is a strong second line of defense, not a replacement for fixing the flaw.
Is server-side file monitoring enough to find an injected skimmer?
Not on its own. It helps when the attacker changed files on your server, but it does not see changes made by a third party's script or by an add-on that runs in the browser. Checking what the browser receives covers that gap.

Read the full guide: XSS, DOM Tampering and Injected Skimmer Code6 min read

Standards (PCI DSS)

What 6.4.3 and 11.6.1 ask for, why they exist, and how they apply to your SAQ.

Why PCI DSS Requirements 6.4.3 and 11.6.1 Exist

The PCI SSC added 6.4.3 and 11.6.1 to PCI DSS v4.0 to counter e-skimming. The threat, the timeline, v4.0.1 and what became mandatory on 31 March 2025.

PCI DSS requirements 6.4.3 and 11.6.1 were introduced in PCI DSS v4.0 (published 31 March 2022) to reduce e-skimming: the theft of card data by malicious scripts running in a shopper's browser. Both started as future-dated requirements and became mandatory on 31 March 2025. 6.4.3 is about managing the scripts on payment pages; 11.6.1 is about detecting unauthorized changes to those pages and their HTTP headers.

Key takeaways

  • Requirements 6.4.3 and 11.6.1 were added in PCI DSS v4.0 (31 March 2022) to reduce e-skimming in the shopper's browser.
  • Both were future-dated and became mandatory on 31 March 2025; v4.0.1 (11 June 2024) is the current version and added clarifying notes.
  • 6.4.3 manages which scripts run on payment pages; 11.6.1 detects unauthorized changes to those pages and their HTTP headers.
  • The March 2025 information supplement is guidance, not a requirement.
  • How the requirements apply to you depends on how you accept payments and what your acquirer and assessor decide.

Frequently asked questions

When did PCI DSS 6.4.3 and 11.6.1 become mandatory?
On 31 March 2025. They were published as future-dated requirements in PCI DSS v4.0 on 31 March 2022 and treated as best practices until that date.
Which version of PCI DSS applies today?
PCI DSS v4.0.1, published on 11 June 2024. Version 3.2.1 was retired on 31 March 2024 and v4.0 on 31 December 2024. Check the PCI SSC document library for any later version.
What is the PCI SSC information supplement on e-skimming?
It is a guidance document published in March 2025, titled Payment Page Security and Preventing E-Skimming: Guidance for PCI DSS Requirements 6.4.3 and 11.6.1. It gives practical strategies for merchants and third-party service providers, and does not replace or add to the requirements.
Do 6.4.3 and 11.6.1 apply if I use a hosted payment page or iframe?
They can. PCI DSS v4.0.1 notes that they also apply to a web page that includes a payment provider's embedded form. For eligible SAQ A merchants the validation works differently. Confirm with your acquirer or assessor how it applies to you.

Read the full guide: Why PCI DSS Requirements 6.4.3 and 11.6.1 Exist6 min read

PCI DSS 6.4.3 Explained: Payment Page Scripts

PCI DSS 6.4.3 requires every payment page script to be authorized, integrity-assured and inventoried with a written justification. What it means.

PCI DSS requirement 6.4.3 says that every script loaded and executed in the consumer's browser on a payment page must be managed in three ways: a method confirms the script is authorized, a method assures its integrity, and an inventory records every script with a written business or technical justification. It applies to your own scripts as much as third-party ones, and it has been mandatory since 31 March 2025.

Key takeaways

  • Requirement 6.4.3 has three parts: authorize each script, assure each script's integrity, and keep an inventory with a written justification.
  • It covers every script that runs in the consumer's browser on the payment page, including first-party and tag-manager-loaded scripts.
  • It became mandatory on 31 March 2025.
  • The standard leaves the method to you; combining techniques usually covers more cases than any one.
  • Evidence has to show a living process: a current inventory that matches reality, approvals and change handling.

Frequently asked questions

Does 6.4.3 apply only to third-party scripts?
No. It covers all payment page scripts that are loaded and executed in the consumer's browser, whether you wrote them, host them or load them from a third party.
Does a Content Security Policy satisfy 6.4.3?
A CSP can be a strong part of the authorization method because it enforces which sources may run. It does not by itself assure that an allowed file has not been altered, so it is usually combined with integrity measures. Your assessor decides whether your combination meets the requirement.
What counts as a written justification?
A short statement of the business or technical reason the script is necessary on that payment page, specific enough that a reviewer can judge whether it is still needed. "Analytics" is weaker than naming what is measured and why it must run on the payment step.
Does 6.4.3 apply if I use a payment provider's iframe?
PCI DSS v4.0.1 says the requirement also applies to scripts on a web page that includes a provider's embedded form, while eligible SAQ A merchants meet a related eligibility criterion instead. Check with your acquirer or assessor.

Read the full guide: PCI DSS 6.4.3 Explained: Payment Page Scripts6 min read

PCI DSS 11.6.1 Explained: Change and Tamper Detection

PCI DSS 11.6.1 requires alerts on unauthorized changes to payment page content and HTTP headers as received by the browser, at least every 7 days.

PCI DSS requirement 11.6.1 requires 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's browser. It must evaluate the headers and pages and run at least once every seven days, or at the frequency set in a targeted risk analysis under requirement 12.3.1. It has been mandatory since 31 March 2025.

Key takeaways

  • Requirement 11.6.1 requires a mechanism that alerts personnel to unauthorized changes to payment page content and HTTP headers.
  • It must evaluate what the consumer's browser receives, not only your source code or origin server.
  • It runs at least once every seven days, or at the frequency in a documented targeted risk analysis (12.3.1).
  • The standard does not name a tool; be ready to explain how your approach meets the intent.
  • It has been mandatory since 31 March 2025; keep evidence of runs, alerts and decisions.

Frequently asked questions

How often must the 11.6.1 mechanism run?
At least once every seven days, or periodically at the frequency defined in your targeted risk analysis performed under requirement 12.3.1. A longer interval needs that documented analysis behind it.
Is monitoring my code repository enough for 11.6.1?
No. The requirement is about the headers and payment pages as received by the consumer browser. Repository checks do not show what a tag manager, a CDN or a third-party script adds at delivery or at runtime.
What counts as an unauthorized change?
A change that nobody with the right to decide approved: a new or removed script, altered script content, or a weakened or removed security header. This is why the approval records of requirement 6.4.3 and the alerts of 11.6.1 work together.
Does 11.6.1 apply if I use a payment provider's iframe?
PCI DSS v4.0.1 says it also applies to a web page that includes a provider's embedded payment form, while eligible SAQ A merchants meet a related eligibility criterion instead. Check with your acquirer or assessor.

Read the full guide: PCI DSS 11.6.1 Explained: Change and Tamper Detection5 min read

PCI DSS 11.6.1 Evidence: What to Show Your Assessor

What to prepare for PCI DSS 11.6.1: the mechanism, the payment pages it covers, run records at least every 7 days, alerts and the decisions made.

For PCI DSS 11.6.1 you need to show an assessor that a mechanism for detecting changes and tampering exists, that it covers your payment pages and their HTTP headers as the consumer's browser receives them, that it runs at least every seven days (or at the frequency in your targeted risk analysis), and that people are alerted and act. In practice that means six things: a description of the mechanism, the list of pages it covers, proof of what it evaluates, a dated history of runs, a record of alerts and the decisions taken, and the risk analysis if you do not run weekly.

Key takeaways

  • Organize 11.6.1 evidence into six items: the mechanism, the pages it covers, what it evaluates, run history, alerts with decisions, and the risk analysis if not weekly.
  • The requirement is about headers and payment pages as received by the consumer browser, so show that your check sees what a browser receives.
  • A history of dated results matters as much as the tool; keep it for the whole assessment period.
  • Name who receives alerts and record what they decided for each change.
  • Your assessor decides what is sufficient; confirm the details with them early.

Frequently asked questions

What evidence do I need for PCI DSS 11.6.1?
A description of the mechanism that detects changes and tampering, the payment pages it covers, proof that it evaluates the HTTP headers and page content as received by the consumer browser, dated results from runs at least every seven days (or at the frequency in your targeted risk analysis), and a record of alerts and the decisions taken.
Is a screenshot of my monitoring tool enough?
Usually not by itself. A single screenshot shows one moment; the requirement is about a mechanism that runs on a schedule and alerts people. Keep exportable, dated results and the alert records, and ask your assessor what format they accept.
What if I do not run the check weekly?
The requirement allows a different frequency only if it is set by a targeted risk analysis performed according to requirement 12.3.1. Keep that analysis and its review with the other evidence.
Does the evidence need to include pages behind a login?
If a payment page is part of your payment flow, it is in scope however it is reached. Show that your mechanism evaluates those pages too, not only the public ones.

Read the full guide: PCI DSS 11.6.1 Evidence: What to Show Your Assessor6 min read

6.4.3 and 11.6.1 for SAQ A, SAQ A-EP and SAQ D

How PCI DSS 6.4.3 and 11.6.1 apply to SAQ A, SAQ A-EP and SAQ D merchants, and the 2025 SAQ A change. Always confirm with your acquirer.

Which SAQ you complete, and how you accept payments (redirect, iframe or direct post), changes how 6.4.3 and 11.6.1 reach you. In early 2025 the PCI SSC removed both requirements from SAQ A and added an eligibility criterion that the merchant has confirmed its site is not susceptible to script attacks; they remain in SAQ A-EP and SAQ D. The rules are revised from time to time, so confirm with your acquirer or assessor what applies to you.

Key takeaways

  • How 6.4.3 and 11.6.1 reach you depends on whether you redirect, embed an iframe or post card data directly, and on the SAQ you complete.
  • SAQ A no longer lists 6.4.3, 11.6.1 or 12.3.1 but requires you to have confirmed your site is not susceptible to script attacks; FAQ 1588 explains how, for sites that embed a payment form.
  • The requirements remain in SAQ A-EP and SAQ D.
  • FAQ 1331 (revised August 2026) cautions against using SAQ criteria to decide applicability in a Report on Compliance without your acquirer's agreement.
  • Always confirm with your acquirer or assessor; these documents are revised over time.

Frequently asked questions

Do SAQ A merchants have to meet 6.4.3 and 11.6.1?
They are no longer listed as requirements in SAQ A. Instead, SAQ A has an eligibility criterion that the merchant has confirmed its site is not susceptible to script attacks. For sites that embed a payment form, FAQ 1588 says this can be met with techniques such as those in 6.4.3 and 11.6.1, or with written confirmation from the compliant payment provider. Confirm with your acquirer.
Does the SAQ A script criterion apply if I redirect customers to a hosted payment page?
According to FAQ 1588, no: the criterion applies to sites that embed a third-party payment page or form, and redirects are excluded.
Do SAQ A-EP merchants need 6.4.3 and 11.6.1?
Yes. The requirements remain in SAQ A-EP, because the merchant's own page influences how card data reaches the payment provider.
Who decides which SAQ I complete?
Your acquirer or the payment brands, who are the compliance-accepting entities, together with your assessor if you use one. The PCI SSC publishes the standard and the questionnaires but does not enforce compliance.

Read the full guide: 6.4.3 and 11.6.1 for SAQ A, SAQ A-EP and SAQ D6 min read

PCI DSS Client-Side Security Checklist

A practical checklist for client-side security under PCI DSS: payment page scope, 6.4.3, 11.6.1, 12.3.1, related 6.x controls and 12.8 vendors.

Client-side security under PCI DSS comes down to a short list of questions: which pages are payment pages, which scripts run on them and who approved each, how their integrity is assured, how unauthorized change would be detected and acted on, and how the third parties involved are managed. This checklist groups those questions around requirements 6.4.3, 11.6.1, 12.3.1 and 12.8, with the related controls that support them. Use it to prepare for a conversation with your assessor, not as a substitute for the standard.

Key takeaways

  • Start with scope: know which pages are payment pages and how each accepts payment.
  • Requirement 6.4.3 asks for authorization, integrity assurance and an inventory with written justification for every payment page script.
  • Requirement 11.6.1 asks for alerts on unauthorized changes to payment page content and headers as the browser receives them, at least every seven days or per your risk analysis.
  • Third-party service providers fall under 12.8, and incident readiness under 12.10.
  • Keep evidence over time: it should show a living process, not a one-off exercise.

Frequently asked questions

What are the PCI DSS requirements for payment page security?
The two requirements aimed directly at payment page scripts are 6.4.3, which covers authorizing, assuring the integrity of and inventorying scripts, and 11.6.1, which covers detecting unauthorized changes to payment pages and HTTP headers. Related controls include 6.4.2, 6.3.2, 12.3.1 and 12.8.
Is this checklist enough to pass an assessment?
No. It is a preparation aid. Your assessor or acquirer decides what applies to you and what evidence is sufficient, and compliance depends on your whole program.
How often should the checklist be reviewed?
Treat the script inventory and detection results as continuous, review the targeted risk analysis at least every twelve months, and revisit scope whenever you change how you accept payments.

Read the full guide: PCI DSS Client-Side Security Checklist6 min read

Defenses

Security headers, Content Security Policy, Subresource Integrity, inventories and detection.

HTTP Security Headers for Payment Pages Explained

CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy, nosniff and Cache-Control: no-store explained for payment pages, and header tampering.

HTTP security headers are instructions your server sends with each page that tell the browser how to treat it: which scripts to trust, whether to use HTTPS only, who may frame the page, what to share with other sites and what to store. For a payment page the most important are Content-Security-Policy, Strict-Transport-Security, frame protection, Referrer-Policy, Permissions-Policy, X-Content-Type-Options and Cache-Control. PCI DSS 11.6.1 asks you to be alerted when headers change without authorization, because weakening a header is a common step in an attack.

Key takeaways

  • Security headers switch on browser protections; they are cheap to send and effective when set well.
  • For payment pages, the key headers are CSP, HSTS, frame protection, Referrer-Policy, Permissions-Policy, X-Content-Type-Options and Cache-Control: no-store.
  • Weakening or removing a header is a common step in an attack, and it does not change how the page looks.
  • PCI DSS 11.6.1 asks for alerts when HTTP headers change without authorization.
  • Build the CSP for your own pages and test in report-only mode first.

Frequently asked questions

Which HTTP security headers are most important for a payment page?
Content-Security-Policy is the most powerful, followed by Strict-Transport-Security, frame protection (CSP frame-ancestors, with X-Frame-Options for older browsers), Referrer-Policy, Permissions-Policy, X-Content-Type-Options and Cache-Control: no-store.
Does PCI DSS list the headers I must set?
Requirement 11.6.1 speaks of alerting on unauthorized changes to the HTTP headers of payment pages as received by the browser; it is a detection requirement and does not give a fixed list of headers to set. Which headers matter for your pages is a decision to explain to your assessor.
Is X-Frame-Options still needed if I use frame-ancestors?
Modern browsers honor the CSP frame-ancestors directive, which is more flexible. X-Frame-Options is still sent by many sites for older browsers. If both are present, browsers that support frame-ancestors use it.
Can I set a Content Security Policy in a meta tag instead?
Partly. A meta tag can carry most CSP directives, but not frame-ancestors, report-uri or sandbox, and it applies only after the browser has parsed it. A real HTTP header is the better choice.

Read the full guide: HTTP Security Headers for Payment Pages Explained6 min read

Content Security Policy (CSP) for Payment Pages

CSP for payment pages: script-src, nonces, hashes, strict-dynamic, why unsafe-inline and wildcards defeat it, report-to and report-only mode.

A Content Security Policy is an HTTP header that tells the browser which sources of scripts, frames, images and connections a page may use, and where it may send data. On a payment page a strict policy based on nonces or hashes can stop injected skimmers from running and limit where stolen data can go. Allow-lists of hosts, 'unsafe-inline' and wildcards weaken it badly, and it needs testing in report-only mode before enforcement.

Key takeaways

  • A CSP can stop injected script from running and limit where a page sends data, which makes it one of the strongest browser-side controls.
  • script-src with nonces or hashes (and optionally strict-dynamic) is far stronger than a list of allowed hosts.
  • 'unsafe-inline', 'unsafe-eval', wildcards and data: sources weaken or defeat a policy.
  • Roll out in report-only mode, review reports, then enforce.
  • A CSP supports 6.4.3 but does not replace integrity checks, and as a header it should itself be monitored under 11.6.1.

Frequently asked questions

What does unsafe-inline do in a CSP?
It allows any inline script and inline event handler to run, including one an attacker injects, which removes most of the protection against XSS and skimmers. When a policy also has a nonce or a hash, modern browsers ignore unsafe-inline.
Should I use nonces or hashes?
Use nonces when pages are generated for each request, because a fresh nonce per response is the most flexible. Use hashes for static inline scripts that rarely change. Both are stronger than allow-listing hosts.
Does a Content Security Policy stop skimmers?
It can block a skimmer that loads from an unapproved source and can stop it sending data to an unapproved address. It cannot stop one that arrives inside an allowed script or from an allowed host, which is why it is combined with integrity checks, an inventory and monitoring.
Is report-only mode safe to use on a live payment page?
Yes. In report-only mode the browser enforces nothing; it only reports. That makes it the usual way to learn what a policy would block before you turn enforcement on.

Read the full guide: Content Security Policy (CSP) for Payment Pages7 min read

Subresource Integrity (SRI) Explained

Subresource Integrity (SRI) lets browsers check a script against a hash. How integrity attributes work, what SRI cannot protect, and why it breaks.

Subresource Integrity (SRI) lets a web page say, in the script tag itself, what the exact content of an external file must be. The browser fetches the file, computes its hash and refuses to run it if the hash does not match. SRI protects against a file being changed on the server that hosts it, but it cannot protect scripts that change on purpose, scripts built on the fly, inline scripts or the page that carries the tag.

Key takeaways

  • SRI puts a hash of the expected file in the script tag; the browser blocks the file if its content differs.
  • It needs crossorigin="anonymous" and a CORS header from the file host for cross-origin files.
  • It protects against a changed file on the host, not against dynamic scripts, inline scripts, scripts that load others, or a compromised page.
  • Updates by the vendor will break a pinned script unless you manage hashes and versions deliberately.
  • Use SRI together with CSP, an inventory and change detection.

Frequently asked questions

What does the integrity attribute do?
It tells the browser the expected hash of an external file. The browser hashes what it downloads and runs the file only if the result matches.
Why does SRI need the crossorigin attribute?
The browser can only inspect the content of a cross-origin file for hashing if the server permits it through CORS. The crossorigin attribute makes the request a CORS request, and the server must answer with a suitable Access-Control-Allow-Origin header.
Would SRI have stopped the polyfill.io attack?
Only for sites that had pinned a file by hash, which was hard because the service generated different code depending on the visitor's request. Self-hosting a reviewed copy or removing the dependency were the usual responses.
Does SRI satisfy PCI DSS 6.4.3?
It can be one method for assuring the integrity of static external scripts, which is part of 6.4.3. It does not cover inline or dynamic scripts, and 6.4.3 also needs authorization and an inventory, so it is usually one layer among several. Your assessor decides what is sufficient.

Read the full guide: Subresource Integrity (SRI) Explained6 min read

Tag Manager Security Risk and How to Govern It

Why tag managers widen the client-side attack surface on payment pages, and how to govern them: access, approvals, inventory, CSP and monitoring.

A tag manager lets people add, change and remove scripts on a website from a web console, without a code release. That convenience is also the risk: anyone who can publish can put JavaScript on every page, including payment pages, and the tags they add often load further scripts. Governed well, with tight access, approvals, an inventory and monitoring, a tag manager can be used safely; ungoverned on a payment page, it is a standing opening for a skimmer.

Key takeaways

  • A tag manager turns publish rights into code execution on every page, including payment pages.
  • Tags often load further scripts, so the console list does not show everything that runs.
  • The strongest control is to keep marketing tags off payment pages, or use a separate, restricted container.
  • Limit and protect publish access, require approvals and keep version history and audit logs.
  • Compare what the payment page really loads with the approved list after every publish.

Frequently asked questions

Should I load a tag manager on my checkout page?
Each tag manager on a payment page widens the attack surface. Many organizations leave it off the payment step or use a separate container with a short, reviewed list. If you do load it, apply tight access, approvals and monitoring.
Do PCI DSS requirements cover scripts loaded by a tag manager?
Yes in effect: requirement 6.4.3 covers all scripts loaded and executed in the consumer's browser on a payment page, whatever loads them. Your assessor decides how it applies to your environment.
How can I audit what a tag manager is doing?
Review the container's version history and audit log, compare the list of tags with your approved inventory, and, most importantly, observe what the payment page actually loads in a browser after each publish.
Does server-side tagging remove the risk?
It reduces third-party code in the visitor's browser, but it does not remove the need for access control, approvals and monitoring, and it shifts trust to your server-side setup.

Read the full guide: Tag Manager Security Risk and How to Govern It6 min read

How to Build a Payment Page Script Inventory

How to discover, document and justify every script on a payment page, what to record, and what an assessor expects as evidence for PCI DSS 6.4.3.

A payment page script inventory is a current list of every script that runs on each payment page, with who approved it, why it is needed, how its integrity is assured and how it is loaded. It has to be built from what the browser actually loads, not from your source code, because tag managers and scripts that load other scripts add code you never wrote. This is the core of PCI DSS 6.4.3 and the evidence an assessor will ask to see.

Key takeaways

  • The inventory lists every script on every payment page, with source, loading method, justification, owner, approval and integrity method.
  • Build it from what a real browser loads, across the whole payment flow and its variations, not from source code alone.
  • Every entry needs a written reason that a reviewer can test; no reason usually means no place on the page.
  • Re-approve scripts when they change, and review the list on a schedule.
  • Assessors look for a living process with history, not a one-time snapshot.

Frequently asked questions

What counts as a payment page for the inventory?
The pages where card data is entered or where a payment form is embedded, and, depending on how you accept payments, pages that can affect them. PCI SSC guidance discusses this in detail; agree the list of pages with your acquirer or assessor.
How detailed does the written justification need to be?
Detailed enough that a reviewer can judge whether the script is still needed: what it does, why the payment page needs it, and who relies on it. A single word such as "analytics" is too thin.
How often should the inventory be updated?
Whenever a script changes, and checked automatically on a schedule that matches your detection frequency (at least every seven days for 11.6.1, unless a risk analysis supports another interval), with a full human review at planned intervals.
Do inline scripts belong in the inventory?
Yes. They run in the browser like any other script. Record what they do and keep a hash or a copy so a change can be seen.

Read the full guide: How to Build a Payment Page Script Inventory6 min read

How to Detect Client-Side Tampering on Payment Pages

Baselines, change detection, monitoring cadence, alerting, incident response and evidence retention for payment page tampering. Vendor neutral.

Detecting client-side tampering means knowing what a payment page should deliver (a baseline of scripts, content and headers), checking what browsers actually receive on a schedule, and alerting people when the two differ, with a clear process for deciding whether the change was authorized. This article describes that process in a vendor-neutral way, including cadence, alerts, incident response and the evidence worth keeping.

Key takeaways

  • A baseline of scripts, content and headers, built from reviewed and approved items, is what makes change visible.
  • Alert on new, removed or changed scripts, altered forms, weakened headers and new third-party domains, and tie alerts to approvals to cut noise.
  • Observe what the customer's browser receives; combine methods and be ready to explain the combination.
  • Weekly is a floor under 11.6.1; many organizations check daily and after every release or publish.
  • Plan the response in advance and keep evidence of runs, alerts and decisions.

Frequently asked questions

How often should I check payment pages for tampering?
PCI DSS 11.6.1 requires at least once every seven days, or the frequency in a documented targeted risk analysis. Many organizations check daily and also after every release, tag manager publish or vendor change.
Can I rely on server-side monitoring alone?
No. It cannot see changes made by third-party scripts, a tag manager or a CDN at delivery or in the browser. Checking what the browser receives covers that gap.
Does detection prevent attacks?
No. Detection shortens the time an attack goes unnoticed. Prevention controls such as a Content Security Policy, integrity checks, patching and access control reduce the chance of a successful attack; the two work together.
What should a good alert include?
The page, the change (before and after), the time it was first seen, whether it matches an approved change, who is responsible for responding, and a link to the evidence.

Read the full guide: How to Detect Client-Side Tampering on Payment Pages6 min read

How to Choose a PCI DSS 6.4.3 and 11.6.1 Tool

Questions to ask any 6.4.3 and 11.6.1 script monitoring tool, and what ten tools say on their own pages, including about pages behind a login.

Tools for PCI DSS 6.4.3 and 11.6.1 differ in how they see your payment page (a real browser outside your site, a script inside the page, a proxy or a content security policy), whether they block or only detect, what evidence they keep and, most of all, whether they can reach payment pages that sit behind a login. Ask every vendor the same nine questions, check the answers in writing, and have your assessor confirm what they will accept. Below, each question is followed by a table of what ten tools say on their own pages.

Key takeaways

  • Ask every vendor the same nine questions and get the answers in writing.
  • The question that separates tools is whether they can reach payment pages behind a login or in the middle of a checkout.
  • None of the nine other pages read for this guide describes logins: cside mentions "the user flow leading to the payment page" and TamperDetect lists "Dynamic & Gated Content" without explaining it. Ask each vendor directly.
  • Detecting and blocking are different capabilities; the requirements ask for inventory, authorization, integrity and alerts.
  • Your assessor decides what is sufficient; confirm early.

Frequently asked questions

Which tool is best for PCI DSS 6.4.3 and 11.6.1?
It depends on how your payment pages are built and delivered. Pages behind a login, third-party payment forms, the evidence you must produce and whether you want blocking or only detection all change the answer. Use the nine questions above and ask your assessor what they accept.
Do I need a tool that blocks scripts?
The requirements ask for an inventory of scripts, a way to authorize them, integrity assurance and alerts on change. Some tools also block; others only detect and report. PCI Monitor only detects and reports, so it works alongside controls such as a Content Security Policy.
Does a monitoring tool have to cover pages behind a login?
If a payment page is part of your payment flow, it is in scope however a customer reaches it. Ask the vendor how the page behind the login is reached and how the tool handles a second sign-in step.
How was the vendor table made?
By reading each company's own page on 23 October 2026 and recording only what it states. No reviews or rankings were used. The publisher makes one of the tools listed; the disclosure is under the table.

Read the full guide: How to Choose a PCI DSS 6.4.3 and 11.6.1 Tool8 min read

Reference

A shared vocabulary for your team, your vendors and your assessor.

Client-Side Security and PCI DSS Glossary

Plain definitions of skimming, Magecart, CSP, SRI, nonce, tag manager, baseline, tamper detection, payment page, SAQ, QSA, ASV and other terms.

This glossary gives short, plain definitions of the terms used across the Security Library: the attacks (skimming, Magecart, formjacking), the browser controls (CSP, SRI, nonce, security headers), the practices (baseline, tamper detection, inventory) and the PCI DSS vocabulary (payment page, SAQ, QSA, ASV, TPSP). Definitions are simplified for orientation; the standards themselves are the authority.

Key takeaways

  • Skimming, Magecart, e-skimming and formjacking all describe card theft by malicious script in the browser.
  • CSP, SRI, nonces and security headers are browser controls; baselines, inventories and tamper detection are practices around them.
  • Requirements 6.4.3 (manage scripts) and 11.6.1 (detect change) are the PCI DSS requirements aimed at payment page scripts.
  • SAQ, ROC, QSA, ASV and TPSP are the roles and documents of PCI DSS validation; your acquirer decides which apply to you.

Frequently asked questions

What is the difference between a CSP nonce and a hash?
A nonce is a random value that changes with every response and is attached to approved script tags. A hash is a fingerprint of a specific script's content. Either lets the browser recognize approved scripts; nonces suit dynamic pages and hashes suit static scripts.
What is the difference between a QSA and an ASV?
A QSA assesses an organization's compliance with PCI DSS requirements. An ASV runs the external vulnerability scans that PCI DSS requires. Both are qualified or approved by the PCI SSC for their roles.
What does "payment page" mean in PCI DSS 6.4.3 and 11.6.1?
Broadly, a page where card data is entered or one that includes an embedded payment form. The PCI SSC's guidance discusses the boundaries, and your acquirer or assessor decides which of your pages count.

Read the full guide: Client-Side Security and PCI DSS Glossary8 min read