DeadTag Protection

Your old tags still load. Someone else owns them now

When an analytics tool, ad network or widget shuts down, its tag usually stays on your pages and its domain goes back on the market. Attackers are buying those domains and selling your visitors on to cybercriminals. Report URI uses reports from your visitors' browsers to audit every script your site loads, and alerts you when any of them change in the future. Then you can block what shouldn't be there.

Trusted by Security Teams

How DeadTag Works

A tag for a dead service is a domain waiting for a new owner

Nothing on your site changes. The line in your page that loads a third-party script stays exactly where it was. What changes is who controls the domain at the other end of it, and that decides what code runs for your visitors.

Abandon

Abandon

A provider shuts down or you switch to something else. The browser asks for the script, gets nothing back and the page carries on, so nobody removes the tag. Eventually the provider stops renewing its domain.

Re-register

Re-register

The DeadTag operators buy the expired domain. From that moment, every site still carrying the old tag loads their code, on every page, for every visitor. We've found around 270 of these domains, still embedded on at least 4,257 websites.

Sell

Sell

A tiny script filters out bots, asks its server about each visitor and redirects the ones someone has paid for. Whoever buys them decides what happens next, from scams to malware to spyware.

Read our research into the DeadTag network and who's buying its traffic, and how it started with one abandoned analytics domain →

What Report URI Does

Find the tags you forgot, before someone else finds them

Your visitors' browsers already know every script your pages load and every server they talk to. Report URI collects that and tells you when it changes. No agents, no injected scripts, no code running on your behalf.

Script Watch

See every tag your pages still load

Script Watch builds an inventory of every script host your pages load, from real visitors' browsers, across every template and every page. That includes the tags added years ago by someone who has since left, the ones inside old CMS plugins and the ones your tag manager still fires. Go through the list and remove anything you no longer use.

Learn more about Script Watch →
CSP Integrity + Script Vault

Know when a tag starts serving new code

CSP Integrity reports the fingerprint of each script your visitors' browsers run. When a domain changes hands, the code behind the tag changes with it, and that shows up as a new fingerprint on a script that hasn't changed in years. Script Vault keeps a copy of what actually ran, so you can see what the new owner served.

Learn more about CSP Integrity → Learn more about Script Vault →
Data Watch

Catch it asking where to send your visitors

The DeadTag script sends details about each visitor to its server and waits to be told where to redirect them. An analytics tag that went quiet years ago has no reason to start making those requests. Data Watch tracks every destination your pages connect to and alerts you when a new one appears.

Learn more about Data Watch →
Threat Intelligence

Know if it's already one of theirs

We track the DeadTag domains we've confirmed, the in-between sites they redirect through and the malicious infrastructure at the end of the chain. Every host in your reports is checked against that list, and a match is flagged on the report itself.

Learn more about Threat Intelligence → Read our threat research →
CSP Enforcement + Integrity Policy

Stop it from running

Once you know what your site legitimately loads, enforce it. An enforced Content Security Policy that no longer lists the dead domain means the browser refuses the script, so nothing is sent and nobody is redirected.

For tags that are a fixed file, Subresource Integrity pins the exact code you reviewed. If a new owner serves anything else, the browser won't run it. Integrity Policy shows you which scripts are still missing that protection.

Learn more about CSP Reporting → Learn more about Integrity Policy →
Why It Gets Missed

Why site owners don't notice a dead tag coming back to life

The site owner did nothing wrong recently, and nothing they control has changed. The usual ways of spotting a problem all come up empty.

Your Codebase

Nothing changed on your side

No deploy, no edited file, no new plugin. File monitoring and code review see the same line they've seen for years. The change happened on a server you don't own.

Your Own Testing

It hides from you

The script does nothing for desktop browsers, bots, data-centre addresses or anyone who has been seen before. You can browse your own site all day and never be redirected.

Security Scanners

Scanners see an empty response

Automated tools get nothing back from the script, which looks exactly like the dead service did. The malicious behaviour only appears in a real visitor's browser.

Your CSP

Your allowlist may still trust it

A Content Security Policy trusts a domain, not whoever owns it. If the old provider is still in your policy, the new owner's script is allowed too. Prune the policy when you remove a service.

Getting Started

Find your forgotten tags in minutes

Old tags live in old templates, so deploy a report-only policy across your whole site. It changes nothing about how your site behaves; it just tells you what loads and what it connects to.

HTTP response header
Content-Security-Policy-Report-Only: script-src 'self' 'report-sha256';
  connect-src 'self';
  report-uri https://your-subdomain.report-uri.com/r/d/csp/reportOnly; report-to default

Add the third parties you actually use today. Anything else that shows up in your reports is a tag to investigate and remove. Once the policy has settled, move it to enforcement.

No agent to install

Sees what loaded for each visitor

Report-only first, nothing breaks

Site functions normally even if Report URI is unavailable

Scope

DeadTag protection: what's covered

Report URI covers what your pages load and where they send your visitors' data. What happens after a visitor has been redirected away, on a site you don't control, is outside any website's reach.

Report URI covers Doesn't replace
An inventory of every third-party script your pages load Your own review of which providers you still use
Detecting changed scripts and new connections Removing the tag from your templates and tag manager
Blocking scripts and destinations you haven't allowed Security updates on your visitors' devices
Matching hosts against known DeadTag and malicious infrastructure Incident response for visitors who were redirected

Nothing of ours runs on your pages, so we never become another tag you have to worry about.

Get Started

See which tags are still loading for your visitors

It's one header, there's nothing to install, and nothing gets blocked until you decide to enforce.

30-day free trial  ·  One header  ·  No infrastructure changes

FAQ

Frequently asked questions

DeadTag is our name for a network that buys the expired domains of shut-down analytics tools, ad networks and widgets. Websites that still carry the old tag load DeadTag's script instead. It filters out bots and sells the remaining visitors to whoever is buying. Read the research.

Third-party tags are written to fail quietly. When the domain stops answering, the browser gets nothing back and the rest of the page loads as normal. That is good for your visitors, but it means nothing prompts anyone to remove the tag.

Deploy a report-only Content Security Policy across your whole site and look at the script hosts in Script Watch. For each one, check it still belongs to a provider you use today. Look beyond your templates: tag managers, CMS plugins and themes often load tags of their own.

No. A Content Security Policy trusts a domain, not whoever owns it. If the old provider is still in your script-src, the new owner's script is allowed too. Remove domains from your policy when you stop using the service. CSP Integrity still flags the changed code, and the script's call home is a connect-src request, which a policy that only lists the domain in script-src will report.

That's up to the buyer, and it changes over time. We've seen the same tag send one visitor to a scam and the next to an exploit kit. Whatever the destination, it starts with a script on your page that you didn't approve.

No. The data comes from a browser feature you turn on with a response header, so nothing of ours executes on your pages. A report-only policy changes nothing about how your site behaves.

Remove it everywhere it is loaded: page templates, your tag manager and any plugin that adds it. Remove the domain from your Content Security Policy too. Then keep reporting in place, so you know if another one comes back to life.