Shadow code: the scripts nobody approved
Code running on your pages that no one currently employed decided to put there. It is more common than most teams expect, and it is where 6.4.3 findings come from.
TL;DR
Shadow code
WHAT IT IS
JavaScript executing on your pages that nobody on the current team approved, and often nobody remembers adding.
WHERE IT COMES FROM
Vendors loading vendors, campaign tags never removed, staff who have left, and platform plugins that ship their own scripts.
WHY IT MATTERS NOW
PCI DSS 6.4.3 requires a written justification per script. Shadow code is by definition the code with no justification.
Short on time? The fastest compliance win available is deleting scripts nobody can justify.
What is shadow code?
Shadow code is any script executing on your website that was not deliberately reviewed or approved by the team currently responsible for the site. It is the web equivalent of shadow IT. Nobody added it maliciously, in most cases nobody added it recently, and it keeps running because removing something nobody understands feels riskier than leaving it. On a payment page it is both an unmanaged attack surface and, since March 2025, a compliance problem: PCI DSS 6.4.3 requires a written business justification for every script, and shadow code is by definition the code that has none.
Requirement 6.4.3 is an authorisation record: every script on the payment page, where it came from, and why it is allowed to be there.
Where it comes from
1
Vendors loading vendors
You approved one company. Their script loaded two more. Nobody chose the last one and it has the same access to the page as your checkout code.
2
Campaign tags never removed
A tag added for a three-week campaign in 2023 that nobody took out, because removal was nobody's job and there was no deadline attached.
3
Staff turnover
The person who added it has left. The tag manager entry has no description, and nobody wants to be the one who broke attribution by deleting it.
4
Platform plugins and themes
Ecommerce plugins ship their own scripts. Installing a review widget or a shipping calculator can add several you never see listed.
5
Acquisitions and agency work
Sites inherited through acquisition, or built by an agency, arrive with a tag set nobody internally has ever audited.
6
Test and debug code
Diagnostic scripts added during an incident and never removed, which sometimes have more access than anything else on the page.
Why inventories miss it
Because most inventories are built from the wrong source. A list assembled from your tag manager shows what is configured in the container. It does not show what those tags loaded afterwards, and it does not show anything added outside the container.
Starting from observed execution inverts this. Every script that ran appears, regardless of who introduced it, which means shadow code shows up as an entry with no owner rather than as a gap you cannot see.
Shadow code shows up as an inventory entry with no owner.
What to do about it
The three-question test resolves most of it quickly. What does this script do on this page. Who owns the decision to keep it. What breaks if it is removed. A script with no answer to the third question is a script to delete, and deleting it is the cheapest risk reduction and compliance work available to you.
For the ones that survive the test but nobody fully trusts, capability blocking is the middle path: keep the script, remove its ability to read form fields.
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
More than teams expect, and the count matters less than the depth. The consistent finding is scripts two and three links away from anything anyone approved. We would rather you measure your own than quote an industry figure at you.
No, and it usually is not. Most of it is forgotten rather than hostile. The risk is that it is unmanaged: nobody is watching whether it changed, and nobody would notice if it did.
Partly right, and worth doing carefully. Some unrecognised scripts are load-bearing for something unexpected, such as fraud scoring or accessibility. Run in monitor-only first so you can see what would break before it does.
No. A container shows what is configured in it. It does not show what those tags loaded afterwards, nor anything injected outside the container, which includes anything an attacker added.
Directly. 6.4.3 requires a written business justification for every script on a payment page. Shadow code is the set of scripts with no justification, so it converts straight into findings.
Naming someone is usually the hard part. The scripts are added by marketing, the page belongs to engineering or ecommerce, and the risk lands on security. Without a named owner the queue does not get worked.
Yes, frequently, and it is often the argument that gets it removed when the security argument does not. Forgotten tags still cost bytes, connections and main-thread time on every page load.
They count too. Anything that executes in the customer's browser on a payment page is in scope for 6.4.3, regardless of who injected it or at what layer.
With a default-deny posture and a weekly queue. If new scripts arrive in a 'requires action' state and someone reviews the change list weekly, accumulation stops being silent.
Yes: look for scripts on payment pages that read form fields or contact destinations not in your approved list. That intersection is small and it is where the genuine problems concentrate.
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
Homoglyph attacks: when a domain is not the domain
Characters that render identically, and why they work so well against script allowlists.
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.