The 'Approval Gap' in Ad Tech: When Marketing Tags Smuggle in Unknown Code
A single approved script on your website can quietly pull in code from vendors your security team has never heard of. Here is why that matters.
Key points
- A marketing tag approved by one team can silently load code from unknown fourth-party vendors, meaning suppliers of your suppliers.
- That hidden code often has full access to web forms, customer data and checkout pages.
- The problem, sometimes called the Approval Gap, sits between marketing, legal and security review.
- Regulators covering payment card and privacy rules increasingly expect companies to know every script running on their site.
- A new on-demand webinar walks security teams through spotting and closing the gap.
Here is the short version. A marketing team gets sign-off for a single tracking script, the small piece of code that measures ad performance or shows a chat widget. That script then quietly loads more code from other companies down the chain. Nobody in security reviewed those extras. Nobody in legal signed a contract with them. They are just there, running inside your customer's browser.
This is what the ad tech industry has started calling the Approval Gap. A new on-demand webinar, flagged this week by The Hacker News, lays out how the gap forms and what defenders can do about it.
Why should a shopper care about a marketing tag?
Because that tag can see the same things you type into the page. Your name. Your card number. Your address at checkout. If a company approves one vendor's script, and that vendor's script loads a second vendor's script, and that one loads a third, you end up with strangers reading over the customer's shoulder.
Security people call those extra strangers fourth parties: the suppliers of your suppliers. Most websites have no clear list of who they are.
The risk is not hypothetical. Attackers have spent years hunting for weak links in this chain. If they can slip malicious code into a small analytics vendor two hops down, they get access to every checkout page that vendor's script touches. That is how large card-skimming attacks (often grouped under the name Magecart) have played out for the better part of a decade.
How the gap actually forms
It usually starts with a reasonable request. Marketing wants to measure a new campaign. They ask IT to add one line of JavaScript to the site. Security reviews that one vendor, ticks the box, and moves on.
What security often does not see is that the approved script is a loader. It calls out to other servers at page load and pulls in whatever code those servers decide to send that day. The list can change without warning. It can grow. It can include partners the original vendor added last week.
So the approval was real. The oversight was not.
A few things make this worse right now.
AI-driven ad platforms swap creative and tracking code much faster than a quarterly review cycle can keep up with. Consent and privacy rules in the EU, UK and several US states now demand that companies know exactly what runs on their pages. Payment card rules under PCI DSS 4.0, the latest version of the card industry's security standard, explicitly require merchants to inventory and monitor every script on payment pages by March 2025.
In plain terms: if you sell online and you cannot list every piece of code running at checkout, you are already behind.
What defenders are being told to do
The webinar's advice lines up with what most application security teams already know but rarely enforce.
Build an actual inventory of every script on customer-facing pages, including the ones loaded indirectly. Set a content security policy, a browser rule that blocks scripts from domains you did not approve. Watch for changes in real time, not once a quarter. Put marketing, legal and security in the same room before a new tag goes live, not after.
None of this is glamorous. It is closer to bookkeeping than threat hunting. But the companies getting hit by web-skimming attacks are almost always the ones that could not answer a simple question: what is running on our checkout page right now?
That is the question the Approval Gap exists to hide. Closing it starts with asking it out loud.
