Real-Time Script Blocking
How the Ours Privacy CMP blocks uncategorized third-party scripts in the browser before they execute, and how that differs from what the Web Scanner reports.
Ours Privacy handles an unexpected third-party script in two layers that work together. The CMP enforces in the moment, and the Web Scanner reports across scans.
- Real-time blocking happens in the visitor's browser. An uncategorized script is stopped before it executes, on the first page view it appears on.
- Scan reporting happens on your scanner's regular schedule. That is when a host you have not categorized, or one that is new or newly high-risk, shows up in your results and triggers a notification.
In short: an uncategorized script is blocked immediately, and reported at the next scan. Enforcement does not wait for a scan, and reporting gives you the history to act on.
Where unexpected scripts come from
Most uncategorized scripts are not an attack. They are ordinary drift in how a site gets built, and they usually arrive one of three ways:
- Someone adds a vendor through a tag manager without telling the team that maintains your consent config.
- An approved vendor loads another vendor at runtime, so a script you never chose appears alongside one you did.
- A vendor changes what its own script does, so code you already classified starts behaving differently.
The common thread is timing rather than intent. None of these wait for your next review cycle, which is why the blocking layer does not either.
How real-time blocking works
Real-time blocking is enforced by the Ours Privacy consent script running on your pages. Because it loads early and wraps the browser APIs that fetch resources, it makes an allow-or-block decision at the moment something tries to load rather than after the fact.
Two things determine the decision:
- Whether the resource matches a service you have configured, and whether the visitor has consented to that service's category.
- Your resource blocking mode, which decides what happens to resources that match nothing you have configured.
In Monitor mode, an uncategorized resource is allowed. In Enforce mode, an uncategorized third-party resource is blocked. Enforce mode is the setting that holds back a script nobody has classified yet.
Put another way: in Enforce mode your configured services act as an allowlist. A third-party resource that is not on it does not run.
Resources served from your own domain and its subdomains are always allowed, in either mode.
For the steps to configure services, categories, and the blocking mode, see Script Blocking.
What the blocking layer covers
Enforce mode applies to resources in the page when it loads and to resources injected later:
- Scripts, including ones written into the page after load and ones created at runtime by other scripts.
- Images, including tracking pixels created at runtime.
- Iframes and stylesheet or preload links.
- Network requests made with
fetch,XMLHttpRequest, ornavigator.sendBeacon.
That last group is what covers the case where a script is already on the page and starts sending data somewhere new. The requests it makes to an unclassified destination are subject to the same decision.
Note: Blocking is best effort by design. A script that a browser has already begun fetching may appear in your browser's network panel even though Ours Privacy prevents it from executing. Load the consent script as early as possible in your HTML so decisions are made before other code runs.
Where blocking shows up, and where reporting does
Blocking and reporting are deliberately separate, because they serve different readers.
Blocking is a per-visitor decision. It happens in browsers you never see, and it is visible in the browser console while you test. It is enforcement, not a record.
Reporting is the record. The scanner crawls your site on its schedule and notifies your team about what needs attention, including hosts you have not categorized. A host is reported as uncovered when it is new since your last scan and matches neither your configured consent services nor a suppression rule. Those arrive alongside newly high-risk and newly escalated hosts in the same findings notification. See How scanning works.
So you do get told about uncategorized scripts, on the scan cycle. What you do not get is one alert per block, because a single uncategorized script would otherwise notify you on every page view. The scan aggregates them into one reviewable list instead.
Using the two layers together
The scanner and the blocking layer answer different questions, and each covers the other's limitation.
| Real-time blocking | Web Scanner | |
|---|---|---|
| When it acts | On page load, per visitor | On each scheduled scan |
| What it does | Stops the resource from executing | Inventories what loaded and flags risk |
| Where you see it | Browser console while testing | Scan results, email, and in-app notifications |
| What it tells you | Nothing on its own, it just enforces | Which hosts are new, uncategorized, or newly high-risk |
| Best at | Keeping an unclassified script from running | Telling you what exists and what to classify |
A practical way to run both:
- Start in Monitor mode and let the scanner build your picture of what actually loads on your site.
- Work through the findings and classify each real vendor into a consent category. See Recommended fixes.
- Once your service list covers your legitimate integrations, switch the rule to Enforce so anything new is blocked on arrival.
- Keep reading scan results. Enforce mode holds back the uncategorized, and the scanner is still how you learn something new appeared and decide whether it belongs.
Important: Turning on Enforce mode before your service list is complete will block integrations you have not classified yet. Validate in Monitor mode first, and use your scan results to confirm coverage.
Next Steps
- Script Blocking: configure services, categories, and Monitor or Enforce mode.
- Regional Policies: run Enforce in one region while another stays on Monitor.
- How scanning works: the scan schedule and change notifications.
- What the scanner detects: third-party scripts, cookies, CSP gaps, and accessibility checks.
Questions about blocking behavior on your site? Reach out to support@oursprivacy.com.
How is this guide?