Why This Matters More Than It Seems

Open your company’s 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.

Analytics, LinkedIn and Google Ads pixels, the CRM, live chat, heatmaps, embedded forms, video and A/B testing tools. On many B2B marketing websites, the list is considerably longer than the team itself realises.

Each of those domains runs code in your visitors’ browsers, under your brand. And almost none has undergone a security review.

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.

What Third-Party Scripts Are and Why a Tag Manager Multiplies Them

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.

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.

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.

The OWASP guide to third-party JavaScript management summarises the problem well. It identifies three main risks: losing control over changes to the client application, executing arbitrary code on users’ devices and leaking information to third parties. It also notes that the greatest risk is a supplier’s server being compromised and malicious code being injected into the original script.

Why A Marketing Script Is an Attractive Target

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.

It Has the Same Privileges as Your Own Code

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.

Nobody Reviews It as Thoroughly As Their Own Code

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.

The Multiplier Effect Works in The Attacker’s Favour

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.

Four Ways the Chain Breaks

1. The Supplier Is Breached

In 2018, the script of a chatbot provider used on Ticketmaster’s website was tampered with to capture customers’ payment details. The weak point was not in the company’s servers, but in an external component that nobody monitored as closely as in-house code.

2. The Domain Changes Hands

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.

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, more than 100,000 websites were loading that domain, and the project’s original author had recommended discontinuing its use after the ownership change. The code redirected some visitors to fraudulent websites.

3. Someone Gains Access to the Tag Manager Account

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.

4. Forgotten Tags

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.

What Is at Stake for a B2B Website

It is easy to assume this is an online retail problem. A B2B website also has plenty to lose:

• Contact and demo request forms that collect the names, job titles, business email addresses and phone numbers of decision-makers.
• Customer areas and portals with access to orders, quotations or documentation.
• B2B stores and payment pages or credit application pages.
• Visitors who work for specific companies. A redirect to a fake page becomes targeted phishing carried out under your company’s brand.

The British Airways incident in 2018 did not start in a tag manager, but with access to the airline’s 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 £20 million fine.

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’s 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.

Controls That Work Without Slowing Down Marketing

The answer is not to ban tag managers, but to treat them as a way of deploying code to production. Their oversight should be part of website maintenance.

Build An Inventory and Assign an Owner to Every Tag

List all external domains loaded by each page type: homepage, blog, forms and customer area. For every tag, record who requested it, what it does, which data it receives and how long it is needed. Review the list quarterly and remove anything without an owner. It is the least expensive measure and does the most to reduce the attack surface.

Secure the Tag Manager Itself

• Enable two-step verification on every account with access.
• Apply least privilege. Google Tag Manager separates read, edit, approve and publish permissions; use that separation.
• Immediately remove agency users and collaborators who no longer work with you.
• Require a second person to review Custom HTML tags.
• Check the version history after any unexpected change.

Remove Tags from Sensitive Pages

Login pages, payment pages and pages with long forms do not need a remarketing pixel or a heatmap. Keep only essential tags on those pages. To measure conversions, an event on the subsequent confirmation page, which does not collect sensitive data, is often sufficient.

Define a Content Security Policy (CSP)

A CSP is an HTTP header that tells the browser which domains it may load scripts from. A basic example:

Content-Security-Policy-Report-Only: script-src 'self' https://www.googletagmanager.com

Start in Report-Only mode: the browser blocks nothing but reports every script that is not on the list. That first report often reveals domains nobody knew were there. With a tag manager, fine-tuning a strict CSP requires testing, so it makes sense to observe before blocking.

Keep one limitation in mind: a CSP cannot distinguish between a legitimate tag and a malicious one published through an already authorised container. It complements access controls for the tag manager rather than replacing them. A misconfigured CSP can also be bypassed: understanding CSP bypass techniques helps you recognise which mistakes to avoid when defining it.

Use Subresource Integrity and Self-Hosted Copies for Stable Libraries

For files that do not change, such as a specific version of a JavaScript library, the integrity attribute lets the browser check that the downloaded file matches what you expected:

<script src="https://cdn.example.com/lib.min.js" integrity="sha384-HASH_DEL_ARCHIVO" crossorigin="anonymous"></script>

If the file changes, the browser rejects it. This does not work for scripts designed to change, such as analytics scripts or the tag manager container itself, but it is very useful for supporting libraries. Better still, host your own copy. In the Polyfill.io case, websites doing so were not affected by the attack.

Monitor Changes

An annual review is not enough. Set up alerts for new domains appearing on your critical pages, review CSP reports and regularly check which scripts actually load in production.

How To Approach This with the Marketing Team

These measures work when marketing sees them as support rather than an obstacle. A simple agreement is often enough: any new tag will be published within 48 hours, in exchange for answers to five questions.

• Who is the supplier, and which domain does the script load from?
• Which data does it receive?
• Has the user given consent where required?
• On which pages will it load?
• When will it be reviewed or removed?

Conclusion: Key Takeaways

Tag managers and third-party scripts are not the problem. The problem is that they are installed as marketing tools but behave like production code, without the reviews applied to in-house code.

• Every third-party script runs with the same privileges as your own code.
• A tag manager moves that list out of your repository: access to its account is as critical as access to the server.
• Real attacks, such as Polyfill.io or Magecart, exploit trust in suppliers and domains, not flaws in your website.
• An inventory, least privilege and fewer tags on sensitive pages offer the best balance between effort and impact.
• A CSP in Report-Only mode and Subresource Integrity add a technical layer without blocking the team.
• A simple process for adding tags gives marketing speed and security visibility.

The next time someone asks to add “just one more pixel”, there is no need to say no. You simply need to know who is adding it, which data it can see and when it will be removed.