Client-Side Security

Data Breach Cost Calculator

A card skimmer costs what it steals. Your visitors' browsers can already see it happen — a script running that you never put there, card details going somewhere you never approved — and every one of them will tell you the moment it does, or refuse to let it happen at all, if you ask them to. Most sites never ask, so the browser notices and says nothing.

Your payment page
Incidents of this kind are commonly described as running around six weeks.
The alert arrives the moment the skimmer first runs. This is how long it takes someone to see it and pull the script.
Reissuance runs $5 to $15, credit monitoring a further $10 to $30.
Depends on how tightly your site is locked down. Naming exactly where your scripts come from and where your pages may send data stops the great majority; leaving either open stops very little.
What one skimmer costs you

Without Report URI

$863,014

57,534 cards exposed. Nobody is told, so it keeps taking cards until something else gives it away.

Monitoring

$20,548

1,370 cards exposed, $842,466 saved. You are alerted the first time it runs, and you take it down.

Monitoring and prevention

$0

Nothing taken. The browser refuses it outright. $860,959 saved


Three years of Report URI

$5,940

Break-even

0.7%

What this model does and does not claim

Enforcement prevents; reporting is how you get there and what catches the rest. A policy that names the origins your scripts load from and the destinations your page may talk to blocks an injected skimmer outright — it never executes, or its exfiltration never leaves the browser. That is prevention, and unlike an alert it does not depend on anyone being awake.

What enforcement cannot stop is an attacker who both runs inside an origin your policy already allows and sends data to a destination it already allows — a compromised script you were loading on purpose. That residual is why the enforced row above is not zero, and why the reports still matter once you are enforcing.

Reporting is also the route to enforcement. Turning on a policy you have not measured breaks the site; report-only mode tells you what would have been blocked so you can enforce without taking the checkout down. That is the sequence this model is really pricing.

It also does not tell you your breach probability. Every vendor model that asserts one picks a number that suits the vendor. This one gives you a break-even instead: the likelihood at which the monitoring has paid for itself. Whether your own risk is above or below that line is your judgement, not ours.

The figures left out all point the same way. Forensic investigation, card-brand assessments, chargebacks, notification, litigation and customer loss are real and none of them are counted here. IBM put the 2026 global average cost of a data breach at $4.99 million, and a drive-by browser compromise at the same figure.

Frequently asked questions

The cost scales with how long the skimmer ran, because that determines how many cards were exposed. Published per-card costs are $5 to $15 for reissuance and a further $10 to $30 for credit monitoring, before forensic investigation, card-brand assessments, chargebacks and litigation. IBM put the 2026 global average cost of a data breach at $4.99 million, and a drive-by browser compromise at the same figure.

Incidents of this kind are commonly described as running for around six weeks before discovery. A skimmer produces no visible symptom for the site owner, which is why it survives so long without continuous monitoring of what executes on the payment page.

A skimmer has to send the stolen data somewhere, and that destination is not in the page's policy, so the browser generates a violation report the first time it runs. Without a reporting endpoint configured, every visitor generates that report and it is discarded. Collecting the reports turns an invisible compromise into an alert.

Both, depending on the mode. An enforced policy blocks it: a script loaded from an origin the policy does not name never executes, and exfiltration to a destination it does not name never leaves the browser, so nothing is stolen and nobody has to read an alert first. A report-only policy does not block, so there the cost is set by how long the skimmer runs before someone acts on the report. What enforcement cannot stop is an attacker running inside an origin you already allow and sending data to a destination you already allow, which is what the reports remain there to catch.

A policy you have not measured will block something your own site depends on, and the first thing you learn is that checkout is broken. Report-only mode tells you exactly what would have been blocked, so you can widen the policy where it is wrong and then enforce with confidence. Reporting is the route to enforcement, not an alternative to it.

Your browsers are already reporting this. Nobody is listening.

Report URI collects the violation reports your visitors' browsers are generating right now, and tells you the moment something new appears on a payment page.