← ALL NOTES
POLICY / / 14 MIN READ

Malvertising Protection: Securing Your Ad Stack Against Bad Actors

Malvertising Protection: Securing Your Ad Stack Against Bad Actors

One in every 133 impressions delivered across premium inventory was dangerous or highly disruptive in Confiant's 2025 MAQ Index, which monitored more than one trillion impressions from January to December 2025 across tens of thousands of premium sites. That figure reflects the vendor's own methodology and footprint, not an industry-wide measure, and it still frames the operational reality: filtering catches most malicious creatives, and what slips through renders on pages carrying your URL in the address bar. For a site above one million monthly pageviews, malvertising is not a theoretical risk. It is a winning bid that fires a redirect or a fake dialog at your user, and then becomes your incident to answer for, with browsers, with advertisers, and with the audience you need to return tomorrow.

A workable defense maps the same chain the attack follows: classification, entry points, inherited enforcement, seller authorization, and the pre-bid and post-bid layers at your edge. Each layer fails in a different way, so each one needs a named owner.

What malvertising looks like on your page

Google's taxonomy is the right starting point because it covers the two forms users report most. Auto-redirects automatically click and unexpectedly take users to another site when rendered: the creative manufactures a click or a navigation without any user gesture. Pop-ups render system dialog boxes over the website, enticing clicks by imitating an operating system alert. Google classifies both as forms of malvertising in its guidance on preventing malware in ad content.

Those are the visible forms. The heavier end of the spectrum drops payload: a creative that quietly loads scripts from an attacker-controlled domain, a fake close button that navigates on any touch, a bait-and-switch creative that passes QA as a clean image and swaps to a redirect once the campaign runs, an out-stream video player that hijacks navigation, a full-screen mobile interstitial that logs a forced tap as a click. None of these need a vulnerability on your servers. The attacker buys the impression through the same channels as a legitimate advertiser and lets your own ad slot execute the payload.

Detection usually starts outside your dashboards. Users complain about redirects before any scanner flags the creative, browsers show warnings before you know the cause, and analytics reveal anomalous exit rates on specific slots during specific hours. Treat every complaint about redirects as a malvertising signal until you prove otherwise, because the pattern is specific: a slot, a geography, a time window, and a demand path that only overlaps part of your traffic.

Keep the categories separate, because the defenses differ. Ad fraud steals advertiser budget with faked impressions or clicks and rarely touches your users. Made for advertising inventory drains spend into junk pages; filtering it protects yield quality, not the reader. Malvertising attacks the person on your page, and the damage lands on your domain: browser blocklists, complaint threads, and advertisers who quietly add you to exclusions after one incident.

Where malicious creatives enter the stack

The primary ad server is where most ad operations teams look first. In 2019, AdExchanger reported on data from the ad security firm GeoEdge showing that roughly 87 percent of observed malvertising attacks arrived through header bidding auctions outside the publisher's primary ad server. Treat the number as dated research rather than a current ratio, since supply paths have multiplied since 2019. The structural finding still holds, because the mechanism has not changed: a header wrapper calls every configured SSP on every impression, each SSP can return demand from its own resellers, and the winning creative renders inside your page without ever becoming a line item you trafficked.

The tradecraft from that same reporting explains why domain blocking alone misses part of the problem. Malvertisers exploited WebRTC infrastructure, where traditional domain-based security does not apply because there is no domain to blacklist. A blacklist cannot block a call that never resolves to an enumerable name, and a pre-bid domain filter cannot screen what it cannot see. Modern scanning handles some of this at the infrastructure level, but the operational lesson stands: block lists are one layer, not the layer.

Supply chain length is the other multiplier. Every hop between the original advertiser and your page is a place where a tag can be swapped, a redirect chain inserted, or a creative replaced after QA. A direct deal is one hop. A resold video tag that passes through two intermediaries before reaching your SSP is several. The longer the chain, the less any single participant knows about the creative that finally renders, and the more you need verification at your own edge.

Attackers probe before they commit. Small test spend across several SSPs identifies which paths serve with the least scrutiny, and the real payload follows the path with the thinnest scrutiny. Your partners therefore do not share the risk evenly: two SSPs with identical volume can carry very different exposure, depending on their pre-bid filtering and their response speed. Mapping that difference, partner by partner, tells you more than any aggregate industry statistic.

How a malicious creative reaches the user
Most observed attacks arrived through header bidding, outside the primary ad server, in dated 2019 ad security research.

The enforcement you inherit from Google

If you run Google Ad Manager, part of the enforcement already surrounds you. Google's proprietary technology and malware detection tools regularly scan all creatives. Google pulls any ad distributing malware, and any Authorized Buyer whose creative contains malware receives a minimum three-month suspension. That suspension is the deterrent that matters: an Authorized Buyer risks a minimum of three months of marketplace access for a single infected creative, so the economics of the attack deteriorate on Google's rails.

Know the boundary of that coverage. The scanning and the suspension regime govern Google's ecosystem, AdX demand and Authorized Buyers. Your header bidding partners sit outside it, each with their own scanning, their own thresholds, and their own response times, and a partner with thin quality operations can pass creatives that Google's pipeline would have caught. Direct campaigns you trafficked yourself receive no external scanning at all. Treat inherited enforcement as a floor, then decide what you add for the paths it does not cover.

Your role inside that regime is reporting and containment. When a Google-served creative misbehaves, capture the same evidence you would capture for a header partner: the creative ID, the slot, the timestamp, and the user agent, then escalate it, because the scanning pipeline works from signals and yours arrive fastest. You also control the exposure surface. In-article units, out-stream video, and mobile interstitials give a redirect the most room to do damage, so those slots deserve the strictest wrapper settings and the shortest partner lists.

Authorized sellers: the perimeter you control

ads.txt is not a compliance formality; it is the inventory's identity system. The file provides regular updates on publishers' approved ad sellers, making it easier to eliminate fraudulent inventory sources and fight domain misrepresentation. Intermediaries can only resell a spoofed version of your domain if someone claims an authorization you never granted, and an accurate ads.txt removes that cover.

The buy side enforces this by default now. Google spells out how DV360 enforces authorized sellers: default targeting includes only authorized direct sellers and resellers, automatically excludes unauthorized inventory, and treats an empty SupplyChain object as unauthorized.

That default carries two operational consequences. First, a stale or inaccurate ads.txt does more than fail to block bad sellers; it can make legitimate inventory unbuyable, because a missing or wrong entry places you outside the authorized set. Second, a partner that does not populate the SupplyChain object becomes invisible to DV360's default targeting even when the chain is legitimate, so the hygiene that protects you also keeps demand flowing.

Verify the chain on real bid responses, not on paper. A SupplyChain object that exists in a partner's documentation but never arrives in the bid stream is an empty object in practice, and DV360 treats exactly that as unauthorized. Pull sample bid responses through each partner, confirm the object arrives complete, and audit the ads.txt file the way you audit revenue: quarterly, against the partners actually serving impressions, with dead lines removed and new lines added only after the first clean payment. If you run apps alongside web, app-ads.txt plays the same role there, under the same discipline.

Certification and the price of an incident

The Trustworthy Accountability Group has run its Certified Against Malware program since 2014, one of the TAG certification programs that set shared accountability standards across the supply chain. The incentive behind certification is commercial, not technical. TAG cites a survey finding that 93 percent of respondents would reduce spending on an advertised product if it infected their devices, and 73 percent would stop purchases altogether. Read that from the advertiser's side: one malware incident attached to a brand does measurable damage to the brand itself, so advertisers respond by hardening the buy side, adding verification, and shrinking the supply paths they trust. A publisher with a public incident ends up on the wrong side of that shrinkage, often without ever learning which budget moved.

Ask every demand partner for certification status, then ask the questions certification does not answer: what they check pre-bid, what they check post-bid, how fast a flagged creative comes down, and whether they tell you when it happens. Certification is a floor. Those four answers tell you what happens at three in the morning when a redirect is live on your site.

Put the answers in the contract. A partner that commits to a response window for flagged creatives, to incident notification on your inventory, and to removal of the responsible demand source has something to lose; a partner that commits to nothing has nothing to lose. Renewal conversations are the leverage point, and malware history belongs in them next to fill rate and CPM.

Building the defense: pre-bid control and post-bid scanning

Effective protection operates at two moments, and you need both. Pre-bid controls run before the creative renders: block lists of known malicious domains applied at the request level, MFA filtering, and brand safety classification aligned to the IAB Content Taxonomy, so junk and spoofed inventory never clears the auction. Pre-bid blocking is cheap per impression and structurally preventive, but it only blocks what someone has already classified. Post-bid scanning inspects the rendered creative in the page: it sees what actually executed, catches bait-and-switch and unclassified payloads, and kills the creative through a wrapper-level override or a forced refresh. A redirect fires at render, so post-bid defense is partly a race, which makes detection speed the metric to interrogate in any scanning product.

We run the first layer ourselves, at scale. At OnlyMedia we are an ad network, an SSP and an agency in one company, and we work with thousands of publishers, each above one million monthly pageviews. Our curation layer sits in front of the auction: managed floors, demand mapping, whitelists, pre-bid brand safety filtering, and MFA filtering aligned to the IAB Content Taxonomy, applied as pre-bid screening on every impression rather than a sampled audit, because sampling leaves the unexamined impressions live.

A stack audit for malvertising exposure can run in this sequence:

  1. Inventory every demand path: primary ad server demand, each header bidding partner, the resellers each partner enables, and every direct-sold tag. You cannot defend a path you have not enumerated.
  2. Audit ads.txt against that inventory: remove dead lines, verify every declared seller, and confirm partners populate sellers.json and the SupplyChain object end to end.
  3. Confirm pre-bid coverage: which domains and attributes are blocked at request level, on which partners, and who maintains the lists.
  4. Confirm post-bid coverage: scanning across every slot and format, including out-stream video and mobile interstitials, with a defined kill mechanism per format.
  5. Test the kill switch: pause a bidder in the Prebid wrapper and a line item in the ad server, and time how long each pause takes to propagate.
  6. Assign monitoring signals to owners: user complaints, redirect reports, scanner alerts, browser warnings, and Search Console malware flags.

The audit usually surfaces three gaps: stale ads.txt lines, unscanned direct tags, and block lists with no owner. Block lists decay on their own, because attackers abandon domains and move payloads to new infrastructure, so a list untouched for months blocks yesterday's attacker. Assign list maintenance to a named owner with a review cadence, and fold incident findings back into the lists the same day: the most valuable entries are the ones you discovered on your own pages.

When an attack is live: incident response

Minutes matter once a redirect fires, because every minute extends the exposure window that ends in blocklists and complaint threads. The sequence is mechanical, and a rehearsed version beats an improvised one:

  1. Reproduce safely: load a clean test page or an isolated slot, and capture the creative URL, timestamp, user agent, and a screenshot before anything changes.
  2. Isolate the path: header bidding partner, primary ad server demand, or direct tag; then pause the bidder in the wrapper, the line item or order in the ad server, or the direct tag respectively.
  3. Notify and demand specifics: the partner needs the creative ID and the payload, and you need their root cause in writing before the partner returns to the wrapper.
  4. Block at your edge: add the malicious domain to pre-bid block lists so the same payload cannot clear the auction again through a different partner.
  5. Watch the following 48 hours: complaint channels, scanner logs, and browser warning reports tell you whether the pause caught everything or a second creative is still live.
  6. Re-enable only after a clean scan, and record the incident: partner, payload, response time, and fix. Repeat incidents from the same partner are grounds to end the relationship.

Assign the roles before the incident: who pauses, who captures evidence, who contacts the partner, who decides on disclosure. Speed comes from ownership, not from process documents. Afterward, decide what you tell advertisers: a short factual note with the timeline and the fix preserves more trust than silence, because the advertisers who care about malware run their own monitoring and will see the incident anyway.

When an incident happens inside a stack we operate, our publisher and partner support desk is the escalation path, and the response process mirrors this sequence.

Live malvertising incident response
Pause the demand path, capture evidence, block the domain, and re-enable only after a clean scan.

The economics: protection as a yield decision

Every demand path you add increases fill and exposure together, and an incident charges you in four currencies at once: user trust, expressed in returning visitor rates; domain reputation, expressed in browser warnings that outlast the incident; advertiser trust, expressed in quiet campaign exclusions; and staff time, expressed in days of forensics instead of optimization. Measured against those costs, pre-bid filtering and post-bid scanning are cheap, and the fill they displace is usually smaller than the fill a domain loses while it carries a warning interstitial.

The commercial terms around filtered demand matter as much as the filtering. At OnlyMedia, we pay publishers Net 30, CPM based, with no chasing and no sliding terms: the impressions that survive curation are the impressions we pay for, on a fixed schedule. Our curated programmatic demand network serves publishers above one million monthly pageviews, and the reporting side runs on a ten minute reporting console, so a quality anomaly surfaces in near real time instead of at month end. Security and payment terms belong in the same sentence, because a monetization partner that filters creatives and pays on time removes both kinds of risk from your operation.

For agencies advising publishers, the audit sequence doubles as due diligence. Run it before recommending a demand stack, weight the recommendation toward partners that pass it, and revisit it at every renewal, because a stack that was clean at signing can pick up a weak reseller a year later.

Malvertising will not disappear, because the attack costs the attacker the price of an impression and costs you far more. That asymmetry is the argument for defense in depth: authorized seller hygiene at the perimeter, inherited scanning in the middle, curation and pre-bid filtering in front of the auction, post-bid scanning at the edge, and a rehearsed response for what still gets through. Run the audit, close the gaps, and make every partner answer for the creatives it serves on your domain.

WRITTEN BY THE DEMAND DESK MORE NOTES →