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 and customer data, including checkout pages.
- The problem, sometimes called the Approval Gap, sits between marketing and security review, with legal caught in the middle.
- 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.
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. Security never reviewed those extras. Legal never signed a contract with them. They're 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 everything 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 don't keep a clear list of who they are.
The risk isn't hypothetical. Attackers have spent years hunting for weak links in this chain. Slip malicious code into a small analytics vendor two hops down and you get access to every checkout page that vendor's script touches. That's 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, so IT adds one line of JavaScript to the site. Security reviews that one vendor, ticks the box, moves on.
What security often doesn't 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 and grow to include partners the original vendor added last week.
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. Privacy rules in the EU and several US states now demand that companies know exactly what runs on their pages. Payment card rules under PCI DSS 4.0, the card industry's security standard, explicitly require merchants to inventory and monitor every script on payment pages. When we covered PCI DSS 4.0's client-side requirements in our 18 June story, an independent assessment found that the script soup on most payment pages was already an auditable surface and most merchants weren't close to ready.
If you sell online and can't list every piece of code running at checkout, you're 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 didn't approve. Watch for changes in real time, not once a quarter. Get marketing, legal and security in the same room before a new tag goes live.
None of this is glamorous. It's closer to bookkeeping than threat hunting. But the companies getting hit by web-skimming attacks are almost always the ones that couldn't name what was running on their checkout page right now.
That's the question the Approval Gap exists to hide. Closing it means asking it out loud, before an auditor or an attacker asks it for you.
