Script blocking at four granularities
Monitoring that can only describe a problem leaves you filing a ticket while the script keeps running. Blocks are enforced at runtime in the browser, alongside your CSP.
Start for free
Talk to an expert
What is script blocking?
Script blocking stops a script from executing, or stops it from doing one specific thing, enforced at runtime in the visitor's browser. It matters for compliance as well as security: some assessors treat a control that can only observe as weaker than one that can also act, which is worth confirming with yours before choosing a tool. It works alongside a Content Security Policy rather than replacing it, because a CSP governs origins and this governs specific scripts and behaviours.
Four granularities
By domain stops everything from an origin. By URL stops one file. By payload hash pins the exact code you approved, so a changed payload stops while the approved one continues. By capability keeps the script running while removing one ability, such as reading form fields.
Why hash-level blocking is the interesting one
It inverts the usual failure. An origin allowlist trusts an address forever, so a compromised vendor serving malicious code from an approved domain passes. Pinning the payload means the approved version keeps working and anything else is a new decision.
Capability blocking, for the vendor you cannot remove
Sometimes the business genuinely needs a tag on the checkout and that tag has no business touching the card field. Removing one capability is a smaller, more defensible action than removing the vendor, and it is usually the one that survives the conversation with marketing.
Blocking by hash pins the exact payload you approved, so a vendor that ships new code has to be re-approved rather than silently inherited.
Related platform capabilities
Script inventory
Every script, with a justification per script.
Tamper detection
Content and integrity changes on the page.
Header monitoring
Distinct values seen per header, per week.
Vendors and load chains
Who loaded whom, and from where.
Monitor-only mode
The same evidence, nothing stopped.
Alerts
Three channels: email, webhook, or S3.
Frequently asked questions
Read the FAQ
Yes, it can if you block something load-bearing, which is why monitor-only mode exists. It reports exactly what would have been blocked and on which pages, so you can see the consequence before anything stops.
Quickly: blocks apply to sessions from the point the rule is live rather than requiring a deployment on your side, because enforcement happens in the tag rather than in your codebase.
No, and it should not. A CSP is a browser-enforced origin allowlist and is worth running regardless. These operate at different levels: the policy decides where scripts may come from, blocking rules decide what specific scripts and behaviours are permitted.
No. A request you blocked is never counted as a page view, so enforcing more does not cost more.
See it on your own payment pages.
Install the tag, mark your payment pages, and watch the inventory fill in. Free forever on 1,000 page views a month, no credit card.
Free forever plan. No credit card.