Boundaries
Published
Advertising code is the one category of JavaScript that is deliberately shipped into a stranger's page, wrapped in an iframe somebody else controls, and inspected on the way by automated systems whose entire function is reading code and deciding whether it looks hostile. Almost every instinct that makes protection worthwhile elsewhere either stops working or actively backfires in that environment, and two of the runtime options break the code outright.
Three parties, three completely different answers
“Ad tech JavaScript” covers at least three kinds of code that share nothing except a slot on a page, and the advice for them diverges immediately. Getting this wrong is why the question feels unanswerable when it is asked in general terms.
The creative is what the advertiser ships: the markup and script that render an ad unit. It executes inside a frame, on a page nobody involved in writing it has seen, and it passes through review systems on the way. The integration layer is what a publisher runs on their own page: a header bidding wrapper, its adapters, the tag that requests and places ads. And the proprietary decisioning is whatever your business actually competes on: pricing, targeting, yield, fraud scoring. That third one is where all the value sits, and it is the one category that has no business being in a browser at all.
Protection has something to offer exactly one of the three, and it is not the one people ask about.
A creative does not run on your hostname, and the domain lock knows it
This is the concrete, checkable finding that decides the question for creative code, and it is worth reading the emitted guard rather than reasoning about it abstractly.
The domain lock compiles down to a small function that reads location.hostname of the document the guard is running in, lowercases it, and compares it against your allowlist. Before it ever consults the list, it checks whether the hostname is empty — and if it is, the failure action fires immediately. That single ordering decision is what makes domain locking unusable in an ad slot, because both of the ways a creative gets rendered land on the wrong side of it.
Rendered into a cross-origin frame, the creative's document belongs to the ad server, so location.hostname is the exchange's host and not the publisher's. Your allowlist contains neither, so the check fails. Rendered into the other common arrangement — a frame the page writes into directly, with a document that has no real URL — the hostname is the empty string, and the guard fires its failure action before the allowlist is read at all. There is no allowlist entry that fixes either case, because the host you would need to list is not yours and, in the second case, does not exist.
The result is a build setting that produces a blank ad unit on a delivery path you cannot inspect, discovered as a fill-rate anomaly days later. This is the same mechanism that makes domain locking useless against a hostile embedder, seen from the other side: the guard cannot tell where it is, so it either passes when you wanted it to fail, or fails when you needed it to pass.
The integrity guard has no working premise in an ad slot
The anti-tampering option fingerprints a list of built-in functions at startup and re-checks them on a short interval, treating replacement as evidence of interference. Its default list is precisely the surface a page full of other people's scripts disturbs: the network functions, the timers, the event registration method, the beacon function, the storage accessors, several array and object built-ins.
That option is built on an assumption — that on a normal page, nobody replaces the built-ins. On a monetised page the assumption is simply false. Consent tooling wraps network calls. Analytics wraps them again. A tag manager wraps whatever it is asked to. Viewability measurement instruments timers and event listeners on purpose. Every one of those is legitimate, expected, and indistinguishable to the guard from the thing it is looking for. You are not detecting an attack; you are detecting the industry.
The same reasoning applies to the other runtime guards. Blocking developer-tools shortcuts on a page you do not own is presumptuous and trivially bypassed. The browser and operating system locks classify an unrecognised agent as unknown, which is never in an allowlist, so anything unusual fails closed — and ad inventory is full of unusual agents.
Everything a scanner needs to distrust you, you supplied
Advertising is one of the few delivery channels where automated code review is a routine, adversarial part of the pipeline rather than an occasional inconvenience. Creative review systems, malvertising detection, brand safety tooling and endpoint security products all work the same way: fetch the code, read it, and score how much it resembles known-bad behaviour.
What known-bad looks like, in this specific channel, is heavily transformed script with string tables, indirect calls, environment checks and network activity assembled at run time. That description also fits a legitimately protected bundle exactly, which is the whole problem. This is not a new observation on this site — it is the same mechanism behind antivirus false positives on protected JavaScript — but in advertising the scanner is not a nuisance downstream of your release. It is standing between you and delivery, and it decides.
Policies vary by exchange and by network, and this page will not tell you what any particular one permits, because that is a contractual question you should confirm with your partner rather than take from a vendor page. What is safe to say is the structural point: you are asking a system that judges code by reading it to approve code built to resist reading, on a channel where the cost of a wrong answer is your delivery rather than a support ticket.
The bid protocol was never secret to begin with
Suppose all of the above were solved. It would still be worth asking what protecting an adapter is meant to conceal, because the answer is close to nothing.
Header bidding adapters are, for the most part, published in the open as a condition of interoperating: an exchange that wants demand connected has an interest in its adapter being readable. The request and response shapes are documented specifications. The auction traffic is visible in the network panel of any browser, on any page running the wrapper, with no reverse engineering involved at all. And the wrapper's own configuration — your floor prices, your timeout values, your list of demand partners — usually sits in the page as data rather than as code, which means the transformations do not touch it in the first place. This is the same shape as a GraphQL document travelling in plain text: protocol is not program, and no build setting makes it one.
So the confidential thing is not in the adapter. It is in what your server does with the bid request after it arrives, which is code no browser ever receives.
Where protection is actually worth the effort
There is a real answer here, and it is on the publisher side rather than the creative side.
Code you host, serve from your own origin and run on your own pages is ordinary first-party JavaScript, and the usual reasoning applies to it in full. If you have built proprietary logic that has to run in the browser — a bespoke lazy-loading and refresh strategy, an in-page yield heuristic, a subscription or consent gate that decides which slots fill, an anti-fraud signal collector — then that is your work, it is worth making expensive to lift, and none of the objections above apply. It runs on your hostname, so the domain lock behaves normally. It runs in your document, so you know what else is on the page. It is not passing through anybody's review queue.
Two habits make that work well. Split the bundle, so the protected proprietary module is separate from the vanilla wrapper and adapters that need to stay legible and stay compatible. And keep the runtime guards off unless you can name the specific behaviour you want them to stop, because a page with third-party tags on it is the worst possible environment for a guard that treats wrapped built-ins as hostile.
The counterparty risk runs the other way too
Publishers reading this from the receiving end have a mirror-image version of the same problem, and it is worth naming because the industry rarely does.
An obfuscated creative in your slot is code you cannot review, executing in a frame on your page, from a party several hops removed from anyone you have a contract with. The reason malvertising is a persistent problem rather than a solved one is exactly this: the delivery chain is long and the code arrives late. Your controls are structural rather than analytical — render creatives in a cross-origin frame rather than a same-origin one, use the sandbox attribute, set a content security policy that constrains where a creative can send data, and prefer partners whose review process you can describe. Reading the creative is not a control you can rely on, which is exactly why the ones that are hard to read should not be treated as an anomaly you can chase individually.
Frequently asked questions
Should we obfuscate an ad creative?
In almost every case, no, and the reasons are structural rather than a matter of taste. A creative executes inside a frame you do not control, on a page you have never seen, after passing through review systems whose method is reading code. Two of the runtime options break outright in that setting. The transformations themselves make your creative resemble the pattern that malvertising detection is trained on. And the confidentiality benefit is close to zero, because there is rarely anything in a creative worth concealing. Confirm the specific rules with your exchange, since policies differ and are contractual.
Why does the domain lock break a creative?
Because the guard reads the hostname of the document it is running in, and a creative is never running in yours. Rendered into a cross-origin frame, the document belongs to the ad server, so the hostname is the exchange's rather than the publisher's and your allowlist matches neither. Rendered into a frame the page writes into directly, the document has no real URL and the hostname is empty, which the guard checks first and treats as a failure before consulting the allowlist at all. There is no allowlist entry that repairs either case.
Why is the integrity guard a poor fit for a monetised page?
Because its premise does not hold there. The option fingerprints built-in functions such as the network calls, the timers, the event registration method, the beacon function and the storage accessors, then treats replacement as evidence of interference. On a page carrying consent tooling, analytics, a tag manager and viewability measurement, several of those built-ins are wrapped by design and by legitimate parties. The guard cannot distinguish that from the behaviour it was built to catch, so what it detects is the normal operation of the advertising stack.
Is there anything confidential in a header bidding adapter?
Very little, and understanding why saves a lot of effort. Adapters are largely published in the open as a condition of interoperating, the request and response shapes are documented specifications, and the auction traffic is visible in the network panel on any page running the wrapper. The wrapper configuration that people actually care about, such as floor prices, timeouts and the demand partner list, usually sits in the page as data rather than as code, so the transformations do not reach it in the first place. The competitive logic lives in what your server does after the request arrives.
Does protected code get flagged by malvertising and brand safety scanners?
It resembles what those systems are built to find, which is enough to create real friction. Heavily transformed script with string tables, indirect calls, environment checks and network activity assembled at run time describes both a protected bundle and a malicious redirect chain, and an automated reviewer sees the same shape in each. This is the same mechanism that produces antivirus false positives on protected JavaScript, with one difference that matters: in advertising the scanner sits between you and delivery rather than downstream of your release.
What ad tech code is genuinely worth protecting?
Code you host, serve from your own origin and run on your own pages, which is ordinary first-party JavaScript with all the usual reasoning intact. A bespoke lazy-loading and refresh strategy, an in-page yield heuristic, a subscription or consent gate deciding which slots fill, a signal collector feeding your fraud model: that is your work, it is worth making expensive to lift, and none of the objections above apply because it runs on your hostname in your document and passes through nobody's review queue.
How should we structure the build if we protect the publisher-side code?
Split it. Keep the proprietary module that deserves protection in its own bundle, and leave the wrapper, the adapters and anything that has to interoperate as plain readable JavaScript. That keeps compatibility problems away from the code most likely to change under you, keeps your protected artifact small enough to reason about, and means an integration partner debugging an adapter is never looking at transformed output. Leave the runtime guards off unless you can name the specific behaviour you want one to stop.
What can a publisher do about creatives they cannot review?
Rely on structural controls rather than analytical ones, because reading the code was never going to scale. Render creatives in a cross-origin frame rather than a same-origin one, use the sandbox attribute to remove capabilities the creative does not need, set a content security policy that constrains where a creative can send data, and prefer partners whose review process you can actually describe. Treating an unreadable creative as an anomaly to investigate individually is not a control, because unreadable is the normal condition of that supply chain.
Related reading