JavaScript injection attacks, explained
Four routes onto your page, ranked by how often they actually happen rather than by how much attention they get.
TL;DR
JavaScript injection
WHAT IT IS
Any technique that results in JavaScript the site owner did not intend executing on the page.
THE FOUR ROUTES
Third-party compromise, tag manager access, application vulnerability such as XSS, and infrastructure or supply chain compromise.
THE UNCOMFORTABLE RANKING
Third-party compromise is the most common and gets the least attention, because it requires no flaw in your own code.
Short on time? You can write flawless code and still have attacker JavaScript on your checkout.
What is a JavaScript injection attack?
A JavaScript injection attack is any technique that causes JavaScript the site owner did not intend to execute in a visitor's browser in the context of that site. The term covers a range of routes with very different causes. Cross-site scripting, where an application flaw allows input to be rendered as executable code, is the best known and the most studied. In the context of payment pages the more common route is simpler and involves no flaw in your application at all: a third-party script you legitimately load is compromised at source, and the attacker's code arrives through a channel you deliberately opened.
Blocking by hash pins the exact payload you approved, so a vendor that ships new code has to be re-approved rather than silently inherited.
The four routes, in order of how often they happen
1
1. Third-party compromise
A vendor whose script you load is breached, and the script they serve changes. Your allowlist passes because the origin is one you approved. No flaw in your code is required, which is what makes it both common and hard to see.
2
2. Tag manager access
A container exists to inject arbitrary JavaScript by design. Credential compromise or an over-permissioned account is enough. No deploy, no code review, no repository access needed.
3
3. Application vulnerability
Classic cross-site scripting: user input rendered as code. The most studied route, the best understood defensively, and no longer the most common on payment pages.
4
4. Infrastructure and supply chain
Compromise of a CDN, a build pipeline, or a dependency pulled in at build time. Less frequent, higher impact, and harder to detect from inside the application.
Where injected code actually comes from
The four routes above describe what an attacker compromises. In practice, the code tends to arrive through one of these doors:
Packages in your build. A compromised npm dependency ships its payload inside your own first-party bundle, served from your own domain.
Tag managers. Containers are often editable by external agencies whose access controls and staff changes you have no view of.
Small marketing tools. Widgets used across thousands of sites change names, move domains and get acquired. The script you approved can end up owned by someone else.
Ad networks. An ad slot is a distribution channel for third-party JavaScript, and what it serves changes constantly.
CMS plugins and extensions. WordPress, Magento and Drupal have a long history of unpatched vulnerabilities that let an attacker add a script without the site owner noticing.
Manual edits. An attacker with write access changes code by hand and makes it run only where you have the least visibility.
The first script is usually clean. The malicious part tends to sit in something it loads later, under conditions that keep it away from security tooling and from the company's own IP ranges.
Why XSS gets the attention and third parties get the incidents
Cross-site scripting is a flaw in code you wrote, so it is something you can fix, test for and train against. That makes it tractable and it has an enormous body of good guidance behind it.
Third-party compromise is not a flaw in anything you wrote. Your code is correct, your dependencies are current, your input handling is sound, and a company three links away in a load chain had a bad week. There is no patch for this, only visibility and control over what you permit.
Detection at the script layer is route-agnostic, which helps when the route is unknown.
What addresses each route
Route
What helps
Third-party compromise
Script inventory, payload hashing, behavioural monitoring, capability blocking. A CSP alone does not, because the origin is allowed
Tag manager access
MFA, least privilege, change review on the container, and monitoring what the container actually publishes
Application XSS
Output encoding, framework defaults, a strict CSP, input validation, and testing
Infrastructure and supply chain
Subresource Integrity where practical, dependency pinning, build provenance, and payload monitoring in production
Detecting injection after the fact
Whatever the route, the outcome is the same and is detectable in the same way: a script executing that is not in your inventory, or an approved script whose payload no longer matches what you approved, or a script doing something it has not done before. Detection at that layer is route-agnostic, which is useful given the route is often unknown until afterwards.
Sources and methodology
PCI DSS requirement text is quoted from PCI DSS v4.0.1 (June 2024), published by the PCI Security Standards Council, which is the current version at the time of writing. Requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025. Where we describe a competitor, we describe publicly available information and say so when something should be verified with the vendor. We publish this product and that is a bias worth knowing about while you read.
ASK AN AI
Don’t just take our word for it
Ask your assistant what to look for in a tool for PCI DSS 6.4.3 and 11.6.1.
Frequently asked questions
No, XSS is one route among several. Cross-site scripting specifically means an application flaw allowing input to be rendered as executable code. JavaScript injection is the broader outcome, and on payment pages the more common route is a compromised third-party script rather than a flaw in your own application.
Partly, and it depends entirely on the route. A strict CSP is a strong defence against XSS and against unlisted origins. It offers no protection when the malicious code arrives from an origin you already allowed, which is the third-party compromise case.
Third-party compromise, by some distance. It requires no flaw in your code, uses a channel you deliberately opened, and passes both your allowlist and your policy.
Partly, and it is rarely practical for tags. SRI pins the exact contents of a file, which is exactly the right idea. It breaks whenever a vendor legitimately updates their script, which is why almost nobody runs it on third-party tags in production.
By comparing against a baseline: a script executing that is not in your inventory, an approved script whose payload hash changed, or a script contacting a destination it has never used. Without a baseline there is nothing to compare against.
Yes, if they run on the payment page. JavaScript on a page has full access to that page's DOM, including every input. The browser enforces no privilege boundary between your code and a third party's.
Partly. Modern frameworks escape output by default, which removes most classic XSS. They do nothing about a third-party script you deliberately loaded, because that script runs as intended.
It deserves more attention than it gets. A container is designed to inject arbitrary JavaScript, so access to it is equivalent to the ability to deploy code, without any of the review that real deploys go through. See tag manager security.
Partly. Inline script is not inherently malicious, and it complicates defence: it has no URL to allowlist and no external file to hash, so identifying it requires hashing the inline content or using nonces.
Inventory. Every defence listed here depends on knowing what is supposed to be executing, and that is also what PCI DSS 6.4.3 asks for first.
Related articles
Attacks
What is Magecart? Groups, methods and real incidents
Where the name came from, how the attacks work, and why they run for months undetected.
Attacks
What is web skimming? How card data leaves the browser
The technique, the exfiltration methods, and why your server logs show a successful checkout.
Attacks
What is formjacking? The mechanism, explained
How a script hijacks a form, the two main implementations, and what detects each one.
Attacks
Shadow code: the scripts nobody approved
Code executing on your pages that no one on your team chose, and how it gets there.
See every script on your own checkout.
Install the tag, mark your payment pages, and watch the inventory fill in. Free forever on 1,000 page views a month, no credit card.
Free forever plan. No credit card.