Your Website as a Security Dashboard: Catching Rogue Scripts Before They Fire

The question I get most often about the Web Scanner is some version of this: "if a bad script shows up on our site on a Tuesday, do we find out on Tuesday, or do we find out at the next scan?"

It's the right question, and for a while we did a poor job answering it. The honest answer has two halves, because two different systems are doing two different jobs. One acts instantly. The other reports on a schedule. Once you see how they divide the work, the answer is straightforward, and you can configure your site so the instant half actually protects you.

The gap between "scanning" and "protecting"

A scanner is a camera. It tells you what was on your site when it looked. That's genuinely useful: it's how you build an inventory, how you find the vendor that a contractor added two years ago, and how you track whether your third-party footprint is growing or shrinking.

But a camera doesn't stop anything. If a script appears on Tuesday and your next scan is days away, a camera-only setup means every visitor in between met that script. For a healthcare site, where the script in question might be reading a URL that contains a condition name or an appointment type, that window is the whole problem.

So the scanner was never supposed to be the protection. The protection is the blocking layer, and it runs on a completely different clock.

Three ways a rogue script actually shows up

"Rogue script" sounds like it means an attacker. Sometimes it does. More often, in my experience with healthcare sites, it's one of these:

Someone adds a tag. A marketer needs a heatmap tool for a campaign, adds it through the tag manager, and it works, so nobody revisits it. It's now loading on every page including the ones with appointment details in the URL.

An approved vendor brings friends. This is the one that surprises people. You approved one vendor. That vendor's script loads another vendor at runtime. Embed a map and you may also get an analytics library and an advertising cookie you never chose. You reviewed one thing and got three.

A trusted script changes. The vendor you vetted last year pushes an update, or their delivery gets compromised upstream. The script name is identical, the domain is identical, and it's now doing something new.

Notice that none of these announce themselves, and two of them involve code you already approved. That's why "review your vendor list quarterly" isn't a real defense, and why the blocking decision has to happen at load time.

The part that acts immediately

The Ours Privacy consent script loads early on your pages and wraps the browser APIs that fetch resources. When something tries to load, it makes an allow-or-block decision at that moment.

What decides the outcome is your resource blocking mode.

Monitor mode blocks resources that match a service you've configured when the visitor hasn't consented to that service's category. Anything that matches nothing you've configured is allowed through. This is the right place to start, and it's the default.

Enforce mode adds the rule that matters for rogue scripts: an uncategorized third-party resource is blocked. Not flagged. Blocked, before it executes, on the first page view it appears on. Your own domain and its subdomains are always allowed.

That inversion is the whole point. In Monitor mode, an unknown script is innocent until you classify it. In Enforce mode, it has to be on your list to run. All three of the scenarios above produce something that isn't on your list, which is exactly why Enforce catches them without you having predicted any of them.

It's worth knowing the blocking isn't limited to