Open your company\u2019s website, press F12 and select the Network tab. Reload the page and look at how many domains you do not own appear in the list.<\/p>\n
Analytics, LinkedIn and Google Ads pixels, the CRM, live chat, heatmaps, embedded forms, video and A\/B testing tools. On many B2B marketing<\/a> websites, the list is considerably longer than the team itself realises.<\/p>\n Each of those domains runs code in your visitors\u2019 browsers, under your brand. And almost none has undergone a security review.<\/p>\n That is the overlooked risk. This article explains how it works, how it has been exploited in practice and which controls you can apply without turning the security team into the department that always says no.<\/p>\n A third-party script is any piece of JavaScript that your website loads from a server you do not control: a library hosted on a CDN, the code for an advertising pixel or a chat widget. When the browser receives it, it runs it as though it were your own code.<\/p>\n A tag manager, such as Google Tag Manager, adds another layer. You install a single snippet on the website and, from that point on, the marketing team publishes tags through a web interface, without involving developers or going through a deployment. That agility is precisely the point, and it is also what changes the risk model.<\/p>\n With a tag manager, the list of scripts running on your website is no longer held in your code repository. It sits in an external account, can be changed by anyone with publishing permissions and can include Custom HTML tags, which are simply arbitrary JavaScript.<\/p>\n The OWASP guide to third-party JavaScript management<\/a> summarises the problem well. It identifies three main risks: losing control over changes to the client application, executing arbitrary code on users\u2019 devices and leaking information to third parties. It also notes that the greatest risk is a supplier\u2019s server being compromised and malicious code being injected into the original script.<\/p>\n An attacker does not need to break into your server if they can compromise a supplier whose code is already running on your website. There are three reasons why this route offers such a strong return.<\/p>\n A third-party script can read what a user types into a form, change the page content, add fake fields, read cookies that are not marked HttpOnly and redirect the visitor elsewhere. The browser does not distinguish between in-house code and supplier code.<\/p>\n In-house code goes through reviews, testing and, with any luck, some penetration testing. Third-party code is copied and pasted in, then treated as trustworthy. It can also change without you doing anything: the supplier updates its file, and your website starts running the new version that same afternoon.<\/p>\n Compromising a popular supplier compromises every website that loads its script at once. It is more efficient than attacking sites individually. That is why third-party scripts are a common target for groups that steal payment details directly from the browser, collectively known as Magecart.<\/p>\n In 2018, the script of a chatbot provider used on Ticketmaster\u2019s website was tampered with to capture customers\u2019 payment details. The weak point was not in the company\u2019s servers, but in an external component that nobody monitored as closely as in-house code.<\/p>\n A script that is legitimate today may no longer be legitimate tomorrow, without a single line of your website changing. All it takes is for the domain serving it to expire or be sold. OWASP had already warned about this scenario.<\/p>\n Polyfill.io is the clearest example. In early 2024, the domain and service were acquired by a Chinese CDN company called Funnull, and the script being served later began injecting malicious code. According to SecurityWeek<\/a>, more than 100,000 websites were loading that domain, and the project\u2019s original author had recommended discontinuing its use after the ownership change. The code redirected some visitors to fraudulent websites.<\/p>\n Anyone who can publish to your container can run code on your website without touching the server or leaving a trace in the repository. An account belonging to a former agency collaborator that was never deactivated, a reused password without a second authentication factor or publishing permissions granted as a temporary workaround are enough.<\/p>\n The campaign ended two years ago, and the agency no longer works with you, but the pixel is still loading. Every orphaned tag is code that nobody monitors, from a supplier that may no longer be maintained, and it continues receiving data about your visitors.<\/p>\n It is easy to assume this is an online retail problem. A B2B website also has plenty to lose:<\/p>\n The British Airways incident in 2018 did not start in a tag manager, but with access to the airline\u2019s network. However, it illustrates the cost of a tampered script on a website: the malicious code captured payment details as customers completed their purchases, affected around 400,000 people and ultimately led the UK regulator to impose a \u00a320 million fine.<\/p>\n There is also a regulatory dimension. When a third-party script loads on your page, the browser contacts that third party directly, sharing the visitor\u2019s IP address and, depending on the circumstances, the referring page and any cookies it already holds. You are responsible for that data transfer, including under the GDPR. If your website takes payments online, PCI DSS 4.0 has required since 2025, under requirements 6.4.3 and 11.6.1, that all payment-page scripts be authorised, justified and inventoried, and that unauthorised changes be detected.<\/p>\nWhat Third-Party Scripts Are and Why a Tag Manager Multiplies Them<\/h2>\n
Why A Marketing Script Is an Attractive Target<\/h2>\n
It Has the Same Privileges as Your Own Code<\/h3>\n
Nobody Reviews It as Thoroughly As Their Own Code<\/h3>\n
The Multiplier Effect Works in The Attacker\u2019s Favour<\/h3>\n
Four Ways the Chain Breaks<\/h2>\n
1. The Supplier Is Breached<\/h3>\n
2. The Domain Changes Hands<\/h3>\n
3. Someone Gains Access to the Tag Manager Account<\/h3>\n
4. Forgotten Tags<\/h3>\n
What Is at Stake for a B2B Website<\/h2>\n
\n
Controls That Work Without Slowing Down Marketing<\/h2>\n