Cross-site scripting (XSS), DOM tampering and injected skimmer code

Cross-site scripting (XSS) in plain terms

Cross-site scripting is a family of flaws that lets an attacker make a victim's browser run the attacker's JavaScript as if it were part of your site. It happens when a site includes data it did not control (a search term, a comment, a form field, a URL parameter) in a page without handling it safely. OWASP describes three common kinds:

• Stored XSS: the malicious input is saved by the site (for example in a review or a profile) and served to every visitor who views it.
• Reflected XSS: the input is sent back immediately in a response, typically through a crafted link that the victim is persuaded to open.
• DOM-based XSS: the flaw is in the page's own JavaScript, which takes data from somewhere such as the address bar and writes it into the page unsafely.

On a payment page, an XSS flaw is dangerous because injected script runs with full access to the form. A skimmer that arrives this way needs no access to your servers at all.

Other ways script reaches a payment page

XSS is only one route. Documented incidents and research describe several more:

• Vulnerable or malicious plugins, themes and extensions. Content management systems and shop platforms rely on add-ons. An out-of-date or poorly written add-on can let an attacker write to files or the database, and a malicious one can contain a skimmer from the start.
• Vulnerable libraries. Old versions of front-end libraries with known flaws can be abused to run script or to alter what the page loads.
• Stolen credentials. Attackers with a valid administrator password, a hosting or FTP login, or access to a deployment pipeline can simply edit a template or a script. Phishing and credential reuse are common sources.
• Compromised third parties. A vendor, tag manager or hosting service that your page already trusts is compromised. See third-party JavaScript risk and tag manager risk.
• Misconfigured storage or CDN. If the place where your scripts are stored is writable by someone who should not be able to write to it, the files can be replaced.

Malware on a customer's own device or a malicious browser extension can also tamper with a page, but that sits outside what the merchant's page controls; the controls in this library address what your site and its suppliers deliver.

What DOM tampering looks like

The Document Object Model (DOM) is the live structure of the page in the browser. Any script allowed to run on the page can change it, and skimmers use that in several ways:

• adding extra fields to a form, or an invisible form that collects the same data;
• listening for key presses or for the form being submitted, and copying the values;
• placing a fake payment form over a real one, or removing an embedded payment iframe and putting a form in its place;
• watching for changes to the page so the skimmer only activates on the payment step;
• wrapping the browser's own request functions so that data sent for a legitimate purpose is also copied elsewhere.

Because these changes happen in the browser, after the page has loaded, the HTML your server sends can be perfectly clean. This is why PCI DSS 11.6.1 speaks of payment pages as received by the consumer's browser, and why a check of the delivered content, not only of your repository, matters. See the explanation of requirement 11.6.1.

How to make injection harder and spot it sooner

Prevent

• Handle data safely when building pages. Encode output for the context it is written into and avoid writing untrusted data into the page with unsafe methods. The OWASP cheat sheets on XSS prevention and DOM-based XSS prevention give practical rules.
• Use a Content Security Policy. A strict policy limits which scripts may run and where data may be sent, and can contain the damage of an XSS flaw. See Content Security Policy for payment pages.
• Consider Trusted Types. This browser feature, currently supported by Chromium-based browsers (check MDN for current support), helps stop unsafe strings from being turned into script.
• Patch promptly. Keep the platform, plugins and libraries up to date and remove those you do not use. PCI DSS requirement 6.3.3 covers installing security patches.
• Protect the ways in. Use multi-factor authentication for administrators, limit who can publish changes, and secure build and deployment systems.
• Develop securely. PCI DSS requirement 6.2.4 covers techniques to prevent common attacks in bespoke and custom software.

Detect

• Compare the scripts and headers a browser actually receives against an approved baseline and alert on differences: how to detect client-side tampering.
• Review your security headers, since an attacker who weakens the Content Security Policy is preparing the ground for a skimmer.
• Monitor file changes on your servers and the audit logs of your content management system and deployment tools.