You have spent months building a secure checkout flow. Your SSL certificate is valid, your server is patched, your passwords are strong. And then an attacker steals ten thousand card numbers by injecting seventeen lines of JavaScript into a script file you load from a CDN. This is a Magecart attack, and it is more common than most merchants realize.
How script injection attacks work
The attacker does not need to break into your systems directly. Instead, they look for a weak link in your JavaScript supply chain:
- Compromised CDN or third-party service. You load an analytics script, a chat widget, or a font library from an external CDN. The attacker compromises that CDN and modifies the script file. Every site that loads the file now runs attacker-controlled code.
- Compromised plugin or dependency. You use an open-source npm package or a WordPress plugin. The attacker takes over the package repository account, publishes a malicious update, and your next deployment bundles the malware.
- Direct server compromise. If the attacker gains write access to your server (via an unpatched CMS, stolen credentials, or a web shell), they can modify your JavaScript files or your HTML templates directly.
Once the skimmer is in place, it silently listens for form submission events on the payment page, captures the card number, expiry date, and CVV as the customer types, and sends the data to an attacker-controlled endpoint - often disguised as a harmless analytics request. The customer sees nothing wrong. The transaction completes normally.
Why it is so hard to catch
The skimmer is typically small - sometimes as short as one obfuscated line of JavaScript. It does not break the page or change anything visible. If you do not have automated monitoring in place, the only way you will know is when your customers report fraudulent charges weeks or months later, or when a card network flags your site during a fraud investigation.
By the time you find out, the attacker may have already moved on and removed all traces of the injection.
The defense: script inventory and monitoring
The most effective defense is knowing exactly what scripts run on your payment page at all times. This means:
- Baseline your scripts. Record every script tag on your checkout page - its URL, its content hash, and whether it has a valid Subresource Integrity attribute.
- Monitor for changes. Check the live page against the baseline at least weekly (PCI DSS 4.0 Requirement 11.6.1 mandates this for all merchants). Any new script, any changed hash, or any SRI failure should trigger an immediate alert.
- Add SRI to scripts you control. If you host your own scripts or load them from a CDN that publishes hashes, add
integrityattributes. The browser will refuse to execute a script whose content does not match the declared hash. - Minimize third-party scripts. Every script you load from an external source is a potential attack surface. Audit your dependencies and remove any that are not strictly necessary on the payment page.
What Shieldome checks
Shieldome's PCI Monitoring feature automates steps one and two. Each weekly scan:
- Fetches the live checkout page (with JavaScript rendering via headless browser when available)
- Collects all
scripttags - inline and external - Downloads and fingerprints each external script file
- Verifies SRI attributes where present
- Compares the result against the stored baseline
- Sends an alert if anything has changed
The full scan history and script inventory are retained as evidence for PCI DSS audits.
Try PCI Monitoring free and know within minutes what is running on your checkout page.