Who adds scripts to your website? Usually not the team that owns it

• Marketing, through a tag manager. A new pixel or chat widget goes live with a click in Google Tag Manager, Adobe or Tealium, with no code review and no deploy.
• Agencies. A campaign, an A/B test or a landing page brings its own tags, and they often stay after the campaign ends.
• Platform plugins and themes. A Shopify app, a Magento extension or a WordPress plugin adds scripts to every page, checkout included, on its own update schedule.
• The vendors you already use. A script you approved loads other scripts. You approved one vendor; its tag decides who else runs.
• AI coding tools. Assistants and agents add libraries and snippets to make something work, faster than anyone reviews them. In Sonar's 2026 developer survey, developers said 42% of their code is now AI-generated or AI-assisted, and only 48% always check AI-assisted code before they commit it.
• Your own developers. Still the one route with a review, a commit and a release.

Only the last route goes through the process most security reviews assume. See tag manager security for how containers load scripts, and building a payment page script inventory for keeping a list that stays true.

A script in the browser can read the page and anything typed into it, change what visitors see, and send data anywhere. It does not matter who added it. A tag added for one campaign has the same access to the checkout as your payment form. And because these routes skip releases, the usual controls never see them: code review, change approval and dependency scanning only cover what goes through the repository.

Attackers use the same routes. Recorded Future counted thousands of e-commerce domains hit by web skimming in the first half of 2025 alone, with infection rates well above early 2024. Recent cases came through a trusted analytics tag (the Plerdy compromise) and a performance script (the DebugBear incident), not through anyone's code review.

On payment pages, 6.4.3 asks for an inventory of every script with a reason it is there, and 11.6.1 asks you to notice unauthorised changes as the browser receives them. Neither cares who added the script. An inventory built from the repository misses every tag manager, agency and plugin script by design.

• List what actually runs on your payment and login pages, from a real browser, not from the repository
• For each script, write down who added it, why, and who owns it now
• Remove tags that no longer have an owner or a reason, starting with checkout
• Ask your tag manager users to keep payment pages out of their containers' triggers
• Agree that new scripts on payment pages need a named owner and a reason before they go live
• Alert on any new script or changed script on those pages, whoever added it

Script Monitoring records every script that runs in real visitors' browsers, with who loaded it and from where, so a tag added through a tag manager, a plugin or an agency shows up the first time it runs. New and changed scripts raise an alert, and you can allow, limit or block each vendor. On payment pages the same record is your evidence for PCI DSS 6.4.3 & 11.6.1. See script inventory and vendor management.

The share of pages with third parties is from the HTTP Archive Web Almanac 2024, Third Parties chapter. The share of websites using Google Tag Manager is from W3Techs' tag manager survey, January 2026; usage figures change month to month. The AI coding figures are from Sonar's 2026 State of Code developer survey (published 8 January 2026, over 1,100 developers, self-reported). The web skimming figures are from Recorded Future's H1 2025 malware and vulnerability trends report. Requirement descriptions are paraphrased from PCI DSS v4.0.1, published by the PCI Security Standards Council. Written on 10 November 2026.