Cryptojacking Protection

Mining is what they chose to do. Not what they could have done.

A cryptojacking attack is proof that somebody can run arbitrary JavaScript on your pages. The mining is almost the mild outcome — the same access, used quietly, reads your forms instead. Report URI catches the injection, not just the symptom.

Start Free Trial Documentation →

What's at Stake

The mining is a symptom. The injection is the breach.

Cryptojacking is attractive to attackers because it monetises access directly, with no stolen data to sell and no payment to launder. But the interesting fact about a mining script on your site is not that it mines. It is that somebody was able to put executable code on your pages at all — and having established that, what runs there is entirely their choice. Mining is simply what they picked this time.

Proven Access

The same route serves any payload

Whatever let a miner onto your page — a cross-site scripting flaw, a compromised dependency, a hijacked tag manager — will just as happily deliver a form skimmer. Removing the miner without closing the route leaves the more damaging version of the attack available.

Supply Chain

It usually isn't your code that was compromised

In 2018 a single compromised accessibility script placed a miner on thousands of sites at once, among them the UK's Information Commissioner's Office and the United States Courts. None of those organisations had been breached directly. Their shared supplier had.

Low Barrier

Cheap to run, so it keeps happening

Mining in a visitor's browser costs the attacker nothing: your users supply the hardware and the electricity. Those economics are why the technique outlasted the news coverage, and why it is still worth detecting rather than assuming it is dated.

How We Help

Detect the new script, then stop it running

Because the underlying problem is unauthorised code execution, the defence is the one that also answers Magecart and cross-site scripting: know what runs on your pages, and let the browser refuse everything else.

Change Detection

A miner is a new script, and new scripts are visible

Script Watch keeps a live inventory of every JavaScript dependency loading on your site and alerts you the first time something appears that was not there before. An injected miner has to load from somewhere, so it shows up as exactly what it is: a dependency nobody added deliberately.

Learn more about Script Watch →

Enforcement

An allowlist the browser applies for you

A Content Security Policy names the sources permitted to execute script on your pages. Anything else is refused by the browser before it runs, and reported to you. That moves the defence from noticing an attack to preventing one — and it applies just as well to code injected through a supplier you trusted.

Learn more about Content Security Policy →

Known Bad Infrastructure

Recognised the moment it appears

Mining pools and the domains serving their loaders are well documented. Threat Intelligence matches what your pages load against indicators of compromise, so a new dependency belonging to known mining infrastructure is not merely unfamiliar — it is identified immediately, without anyone having to research it first.

Learn more about Threat Intelligence →

Get Started

Catch the injection. Not just the mining.

One header. No code. Your script inventory starts populating from the first visitor.

Start Free Trial Talk to our team →

30-day free trial · One header · No code · Cancel anytime

Detection

What gives a miner away

Mining scripts are not especially stealthy, because they have to load, execute continuously and talk to a pool. Each of those is observable from the browser.

Signal	What it tells you
A new script dependency	Something is loading that was not part of your site before
A new subdependency	An existing supplier script has started loading something else
An unexpected connection destination	The page is talking to somewhere it never used to
A threat intelligence match	The source is already documented as mining infrastructure
A blocked script-src violation	Your policy refused it, and told you what it refused
An unrecognised fingerprint	A file whose hash matches nothing known, running on your pages

Every one of these is the same signal that detects a card skimmer, because at the point of injection the two attacks are indistinguishable.

Architecture

One header. No code. No crawlers.

Everything here runs on the browser's own reporting. Your visitors' browsers tell you what loaded and what was refused, so the detection covers pages behind a login, region-specific content and the third-party code a scanner would never be served.

You don't need a working policy to start. A report-only header builds the inventory without blocking anything.

Minimal setup — no existing CSP

Content-Security-Policy-Report-Only: script-src 'self';
  report-uri https://your-subdomain.report-uri.com/r/d/csp/reportOnly

Already running a policy? Add your Report URI endpoint to the existing report-uri directive and detection starts from the reports you already generate.

No code added to your pages

No crawler simulating page loads

Detects code injected through a supplier, not just your own

Your site's performance is unaffected

The same setup defends against skimming and XSS

Case Studies

What it looked like when it happened

The 2018 compromise of a widely-deployed accessibility script put a miner onto thousands of websites simultaneously. Two of them are worth reading in detail, because neither organisation had been attacked directly and neither had done anything obviously wrong: they had included a script from a supplier, as every site does.

That is the shape of the problem. The answer is not to trust fewer suppliers, it is to know what their code is doing on your pages.

The ICO attack → United States Courts →

Scope

One layer in the stack. Here's how it fits.

Cryptojacking is a payload, not a category of defence. What stops it is knowing which code runs on your pages and refusing the rest — the same controls that answer every other injection attack.

Defends by	Using
Alerting on newly appearing scripts	Script Watch for continuous dependency inventory
Refusing unauthorised execution	CSP for browser-enforced allowlisting
Identifying known mining infrastructure	Threat Intelligence for indicator matching
Spotting new data destinations	Data Watch for where your pages send data

Together, these form the client-side security visibility layer that sits between your CSP policy and your incident response process.