Introduction

A Consent Management Platform's most critical technical job is preventing tracking scripts from firing before the user has given consent. Get this wrong and every privacy policy, cookie banner, and preference modal on your site is purely cosmetic, data still flows to third parties regardless of what the user clicked.

There are fundamentally different philosophies about how to achieve this. Some CMPs try to automatically detect and block scripts on your behalf. Others require you to manually tag each script. And a growing number rely on consent signalling protocols that tell scripts to regulate themselves. Each approach has real trade-offs in accuracy, setup effort, and risk of breaking your site.

This guide compares four widely used CMPs, Osano, Cookiebot (now part of Usercentrics), OneTrust, and CookieBeam, to help you understand which script blocking method fits your site and team.

The Two Philosophies

Key Concept

Every CMP uses one or both of these fundamental approaches:

1. Hard blocking, The CMP prevents scripts from executing at all until consent is granted. This can be done automatically (the CMP intercepts and holds scripts) or manually (you change your script tags so the browser ignores them until the CMP activates them). Hard blocking is the most airtight approach: no code runs, no network requests fire, no cookies are set.

2. Consent signalling, The CMP lets scripts load normally but sends machine-readable signals (such as Google Consent Mode's consent command or the IAB TCF TC String) telling each script whether it has permission to track. The script itself decides how to behave based on the signal. This is less intrusive but relies on the vendor's code actually respecting the signal.

In practice, most sites need a combination of both: consent signalling for scripts that support it (primarily the Google ecosystem), and hard blocking for everything else.

The Four CMPs Compared

The table below provides a high-level comparison of how each CMP handles script blocking, detection, and compliance. The details for each CMP follow in the sections below.

CMP Script Blocking Comparison

Feature	Osano	Cookiebot	OneTrust	CookieBeam
Blocking approach	Automatic, intercepts scripts at runtime based on a curated block list	Hybrid, automatic scanner + manual data-cookieconsent tagging; auto-blocking mode also available	Manual, scripts tagged with optanon-category classes; auto-scan for discovery only	Automatic, headless browser scanner builds a script map; runtime engine intercepts scripts and network connections using 5-layer interception (createElement override, DOM insertion hooks, MutationObserver, Worker blocking, anti-tamper). Manual data-category tagging also supported as a secondary method.
Script detection method	Records all script URLs after osano.js loads; matches against regional block list	Monthly crawler scans site and auto-categorises cookies; scripts need manual tagging for hard blocking	Auto-scan discovers cookies and scripts; manual configuration maps scripts to categories	Headless browser scanner (Lambda/CDP) detects scripts, cookies, and network connections automatically. Multi-layer classification pipeline: URL/domain pattern matching, inline script content analysis (23+ vendor patterns), external cookie database, and source grouping. Client-side drift detection continuously monitors for new scripts and connections between scans.
Compliance modes	Listener (discover only), Permissive (block classified, allow unknown), Strict (block all unclassified)	Auto-blocking mode (block unrecognised scripts) or manual mode (only block tagged scripts)	Single enforcement mode, blocks scripts tagged with optanon-category; untagged scripts run freely	Learning mode (allow unknown scripts while building inventory) and Strict mode (block all unclassified scripts by default). Separate toggle for connection-level blocking with its own unknown-connection policy.
Dynamic script handling	Intercepts dynamically injected scripts via MutationObserver	Auto-blocking mode can catch dynamically injected scripts	Limited, primarily handles scripts present at page load	Intercepts all dynamically injected scripts via three independent layers: document.createElement override catches script creation, Node.appendChild/insertBefore/replaceChild hooks catch DOM insertion, and a MutationObserver acts as a fallback catch-all. Also blocks Worker and SharedWorker constructors for third-party worker scripts.
Iframe blocking	Yes, separate iframe blocking feature	Yes, supports data-cookieconsent on iframes	Yes, iframes can be tagged with optanon-category	Yes, iframes are intercepted by the same runtime engine. Blocked iframes get Shield placeholders (visual overlays explaining why the content is blocked) that are replaced with the real content on consent.
Cookie auto-deletion	No, blocks future execution but does not retroactively delete previously set cookies	Yes, can auto-delete cookies when consent is withdrawn	Yes, supports cookie auto-deletion on consent withdrawal	Cleanup scripts via !category prefix for manual cookie deletion on withdrawal
Google Consent Mode V2	Supported	Supported, strong integration with regional defaults	Supported	Native support with configurable regional defaults
TCF support	Not IAB TCF certified	IAB TCF v2.2 certified CMP	IAB TCF v2.2 certified CMP	TCF v2.2 integration available
GTM integration	Basic integration via consent signals	Official GTM template available	Official GTM template available	GTM bridge template for Consent Mode integration
Network connection blocking	No, script-level blocking only	No, script-level blocking only	No, script-level blocking only	Yes, separate connection-level blocking engine wraps fetch(), XMLHttpRequest, navigator.sendBeacon(), WebSocket, and EventSource. Blocks unconsented third-party network requests even from scripts that are allowed to run, with category-aware gating per connection.
Drift detection	No continuous monitoring between scans	Monthly scans detect changes; no real-time monitoring	Periodic scans; no real-time client-side monitoring	Continuous client-side drift detection for scripts, cookies, and network connections. The CDN script monitors for new tracking activity between scans and reports it. Unknown items auto-promote into the inventory after 5 sightings.
Privacy signal enforcement	Basic GPC support	GPC/DNT detection supported	GPC support available	GPC and DNT enforcement built into the blocking engine with per-region overrides. Supports US opt-out regime distinctions (CPRA 7025(b)(3) compliant): a privacy signal sets a default deny, but an explicit in-banner opt-in can override it.
Over-blocking risk	High in Strict mode, known to block reCAPTCHA, payment processors, and essential services	Moderate in auto-blocking mode; low in manual mode	Low, only blocks explicitly tagged scripts	Low, the script map is built from your own scan inventory (not a third-party block list), so the engine only blocks scripts you've reviewed and categorized. Essential services like reCAPTCHA and Stripe are classified as necessary by default and never blocked. Learning mode lets you review unknown scripts before enforcing.
Setup effort	Low initial setup; ongoing effort to fix over-blocking and reclassify scripts	Medium, scanner helps discovery but scripts still need tagging	High, enterprise-grade configuration with complex admin UI	Low to medium. The scanner auto-discovers and classifies scripts, cookies, and connections. You review the inventory in the dashboard, adjust categories where needed, and publish. No HTML changes required for scanned scripts.

Osano: Automatic Discovery and Blocking

Osano takes the most aggressive approach to script blocking. Once osano.js loads as the first script in your <head>, it records all subsequent script URLs and matches them against a curated regional block list. Scripts that match known tracker patterns are intercepted before they can execute.

Osano offers three compliance modes:

Listener mode, Discovery only. Osano observes which scripts load and categorises them, but does not block anything. Use this during initial setup to understand what your site loads.
Permissive mode, Enforces blocking for scripts that Osano has classified as non-essential, but allows any unrecognised script to run. This is a safe middle ground during rollout.
Strict mode, Blocks all scripts that have not been explicitly classified as essential. Any script Osano does not recognise is blocked by default until you manually approve it.

Osano also provides separate features for iframe blocking and localStorage blocking, giving broad coverage over different tracking mechanisms.

The main advantage of Osano's approach is zero-config for site owners, you add one script tag and the CMP handles the rest. However, this comes with a well-documented downside: over-blocking. Osano's Strict mode is known to block essential services like Google reCAPTCHA, payment processors (e.g. Stripe checkout), and authentication services because their URL patterns match entries in the tracker database.

Osano's own documentation explicitly acknowledges that reCAPTCHA blocking is caused by misclassifying required Google URLs as non-essential. The fix requires site owners to manually reclassify these URLs in the Osano dashboard, ironically adding the same manual work that automatic blocking was supposed to eliminate.

It is also important to note that Osano does not retroactively delete previously set cookies after a user revokes consent. Instead, it blocks future script execution, which means cookies set before revocation remain in the browser until they expire naturally or are cleared by the user.

Cookiebot (Usercentrics)

Cookiebot, now part of the Usercentrics group, takes a hybrid approach that combines automatic scanning with manual script tagging.

The core of Cookiebot's system is its monthly cookie scanner. A crawler visits your site, identifies cookies and tracking technologies, and automatically categorises them. This gives site owners a comprehensive inventory without manual auditing.

However, for hard blocking to work, scripts in your HTML still need the data-cookieconsent attribute. The scanner discovers what is on your site; the attributes tell Cookiebot which scripts to block. This means there is still a manual step for each script tag you want to manage.

Cookiebot also offers an auto-blocking mode that works similarly to Osano, it attempts to block scripts without requiring manual tagging. This mode is useful for sites that cannot easily modify their HTML, but it carries the same over-blocking risks as any automatic approach.

On the compliance side, Cookiebot has strong Google Consent Mode V2 integration with support for regional consent defaults. It is also an IAB TCF v2.2 certified CMP, making it suitable for sites that run programmatic advertising and need TCF compliance.

OneTrust

OneTrust is an enterprise-grade platform that takes a tag-level blocking approach. Scripts are managed by adding optanon-category-* CSS classes to script tags (e.g. class="optanon-category-C0002" for performance cookies). When OneTrust initialises, it scans for these classes and activates or blocks scripts based on the user's consent choices.

Like Cookiebot, OneTrust provides an auto-scan feature that crawls your site and discovers cookies and scripts. However, this scan is primarily for inventory and categorisation, you still need to manually configure which category each script belongs to in the OneTrust admin dashboard.

OneTrust's strength is its granular control. The admin interface allows highly specific rules for different regions, cookie lifetimes, consent models (opt-in vs opt-out), and more. For large enterprises managing dozens of domains across multiple jurisdictions, this level of control is valuable.

The trade-off is complexity. OneTrust's setup and configuration require significant effort, and the admin UI has a steep learning curve. It is also among the most expensive CMPs on the market, with enterprise pricing that can be prohibitive for small and mid-sized sites.

On the compliance side, OneTrust is an IAB TCF v2.2 certified CMP with strong support for Google Consent Mode and an official GTM template.

CookieBeam: Automatic Interception with Connection-Level Blocking

CookieBeam combines automatic script interception with a separate connection-level blocking engine, covering both script execution and network requests. The system works in two layers: a headless browser scanner discovers everything on your site, and a runtime engine enforces consent decisions in the visitor's browser.

How the scanner works

CookieBeam runs a headless Chrome scanner (via AWS Lambda and the Chrome DevTools Protocol) that loads your pages like a real browser. It captures three things: cookies, scripts (both external and inline), and outbound network connections. A multi-layer classification pipeline then categorizes each item: URL and domain pattern matching first, then inline script content analysis (recognizing 23+ vendors including GTM containers, Meta Pixel, and Hotjar), then an external cookie database, and finally source grouping (detecting WordPress plugins, theme scripts, and known vendor libraries).

The result is a full inventory in your dashboard. You review the auto-classifications, adjust where needed, and publish. No HTML changes required.

The 5-layer script blocking engine

When you publish, CookieBeam builds a script map from your inventory: a lookup table mapping each discovered script URL to its consent category. The CDN-served runtime engine uses this map to intercept scripts through five independent layers:

document.createElement override: intercepts script, iframe, img, and embed element creation. The engine proxies the src property setter and setAttribute calls, neutralizing elements whose URLs map to unconsented categories.
DOM insertion hooks: wraps Node.appendChild, insertBefore, and replaceChild to catch scripts being added to the page, regardless of how they were created.
MutationObserver fallback: monitors the entire document tree for added nodes and src attribute changes as a catch-all for anything the first two layers miss.
Worker blocking: wraps the Worker and SharedWorker constructors to prevent third-party worker scripts from executing without consent.
Anti-tamper protection: once a script element is neutralized (type set to text/plain, src removed), the engine locks the type property so it can't be reverted to an executable state by another script.

Blocked scripts are neutralized (not deleted) and held in a queue. When the visitor grants consent, the engine revives the relevant scripts in their original order, preserving execution dependencies.

Connection-level blocking

Most CMPs only block scripts. CookieBeam also blocks unconsented network connections at the API level. The engine wraps five browser APIs:

fetch() returns a 204 response with an X-CookieBeam-Blocked header
XMLHttpRequest.send() fires an error event without making the request
navigator.sendBeacon() returns false
WebSocket constructor returns a stub that emits error and close events
EventSource constructor returns a closed stub

This matters because tracking doesn't always happen through script loading. A consented analytics library might make XHR calls to an unconsented marketing endpoint, or a chat widget could open a WebSocket to a third-party tracker. Connection blocking catches these requests individually, gated by their destination's consent category.

Connection blocking is a separate toggle from script blocking, so you can enable it independently. It includes first-party bypass (same-site connections are always allowed) and ignore rules for specific URL patterns.

Drift detection

Scans give you a snapshot, but sites change between scans. CookieBeam's CDN script includes client-side drift detection that continuously monitors for new cookies, scripts, and network connections that weren't in the last scan. When it spots something new, it reports it. After 5 sightings of the same item, it auto-promotes into the inventory so you can categorize it.

This is continuous, real-time monitoring that runs in every visitor's browser, not a periodic scan. If someone publishes a new tag in GTM or a vendor pushes an SDK update that loads a new tracker, drift detection catches it within hours.

Compliance modes

CookieBeam offers two enforcement modes for unknown scripts (those not in the scan-derived map):

Learning mode (default): allows unknown scripts to run while you build your inventory. The scanner and drift detection surface them for review.
Strict mode: blocks all unclassified scripts by default until you explicitly categorize them. This is fail-closed: if an unknown script appears, it's held until you approve it.

For the Google ecosystem, CookieBeam provides native Google Consent Mode V2 support with configurable regional defaults and a GTM bridge template. CookieBeam also supports IAB TCF v2.2 and GPP (Global Privacy Platform).

Privacy signal enforcement (GPC and DNT) is built into the blocking engine. In the EU, a GPC signal sets a default deny that an explicit banner opt-in can override. In US opt-out states, the engine follows CPRA 7025(b)(3): a privacy signal opt-out requires a deliberate, right-specific in-banner opt-in to override, not just a generic "Accept All."

Manual tagging (supplementary)

CookieBeam also supports the traditional data-category and data-src HTML attributes for manual script tagging. This is useful for inline scripts or cases where you want explicit control in your templates. But it's a supplementary method, not the primary blocking mechanism. Most users rely on the scanner-driven auto-blocking and never touch their HTML.

cookiebeam-blocking-engine.html

1 <!-- CookieBeam auto-blocking: no HTML changes needed -->
2 <!-- The scanner discovers this script, you categorize it in
3      the dashboard, and the runtime engine blocks it
4      automatically based on the script map. -->
5 <script src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>
6 
7 <!-- The blocking engine intercepts it at runtime:
8      1. createElement override catches the element creation
9      2. DOM insertion hooks catch appendChild/insertBefore
10      3. MutationObserver catches any that slip through
11      4. Script is neutralized: type set to text/plain,
12         src removed, queued for revival on consent -->
13 
14 <!-- Connection blocking (separate layer): -->
15 <!-- Even if a script runs, unconsented network requests
16      to third-party tracking endpoints are blocked:
17      fetch('https://analytics.example.com/collect')
18      -> returns Response(204, X-CookieBeam-Blocked: 1) -->
19 
20 <!-- Optional: manual tagging for inline scripts -->
21 <script type="text/plain" data-category="analytics">
22   // Inline code that should only run after consent
23   window.dataLayer = window.dataLayer || [];
24 </script>
25 
26 <!-- Cleanup script: runs when user REVOKES consent -->
27 <script type="text/plain" data-category="!analytics">
28   window['ga-disable-G-XXXXXXX'] = true;
29 </script>

The reCAPTCHA Problem

Aggressive auto-blocking CMPs, especially Osano in Strict mode, are known to block essential services like Google reCAPTCHA, payment processors (Stripe, PayPal), and authentication services because their URL patterns match entries in tracker databases.

For example, reCAPTCHA loads scripts from google.com and gstatic.com domains that are also used by Google Analytics and Google Ads. An auto-blocking CMP that blocks all Google tracking URLs will inadvertently block reCAPTCHA, breaking form submissions, login flows, and bot protection across the entire site.

The fix in every case is manual: you must log into the CMP dashboard and reclassify the blocked URLs as "necessary" or add them to an allow list. This effectively negates the main selling point of automatic blocking, you end up doing manual configuration anyway, but only after something breaks in production.

Scanner-based blocking (like CookieBeam's) handles this differently. The scanner discovers scripts and classifies them, but you review and confirm the categories before publishing. Services like reCAPTCHA, Stripe, and Google Fonts are auto-classified as "necessary" by the classification pipeline and never blocked. Because the script map comes from your own reviewed inventory rather than a third-party block list, over-blocking is a configuration choice rather than an accident.

Which Approach Should You Choose?

The right approach depends on your site's architecture, your team's technical capabilities, and which third-party scripts you use. Most sites benefit from a combination of methods.

Choosing Your Script Blocking Strategy

Use manual tag-based blocking if:
You have direct control over your HTML, you want precision over which scripts are blocked, and you want to avoid false positives that break essential site functionality like payments or CAPTCHA.
Use automatic blocking if:
You have many third-party scripts that you did not add yourself, your team is non-technical and cannot modify HTML, or you want a zero-configuration starting point and are willing to fix over-blocking issues as they arise.
Use Consent Mode signalling if:
Your tracking scripts are primarily from the Google ecosystem (GA4, Google Ads, Floodlight), they are loaded through Google Tag Manager, and you want to benefit from cookieless conversion modeling for users who decline consent.
Use a combination if:
You have Google tags that should use Consent Mode (loaded via GTM) plus non-Google scripts hardcoded in your HTML that need manual blocking (Facebook Pixel, Hotjar, TikTok, etc.). This is the most common real-world scenario.

The Industry Direction

Trend

The consent management industry is steadily moving toward Consent Mode signalling, letting scripts self-regulate based on consent state, rather than hard-blocking scripts from loading entirely.

Several forces are driving this shift:

Google officially recommends Consent Mode V2 for all sites using Google tags, and has made it a requirement for personalised advertising in the EEA.
Hard blocking breaks things. Automatic blocking CMPs routinely cause support tickets when essential services are inadvertently blocked. Consent Mode avoids this because scripts still load, they just operate in a restricted mode.
Cookieless conversion modeling. With Consent Mode, Google tags can send cookieless pings (containing no personally identifiable information) even before consent. Google uses these pings for statistical conversion modeling, helping advertisers recover data that would be completely lost with hard blocking.

However, hard blocking remains essential for non-Google vendors that do not support Consent Mode or any equivalent signalling protocol. Facebook Pixel, TikTok Pixel, Hotjar, and dozens of other tools have no self-regulation mechanism, if the script loads, it tracks. For these scripts, the only GDPR-compliant option is to prevent them from executing entirely until consent is given.

Best Practice: Belt and Braces

Use Google Consent Mode V2 for your Google tags (loaded through GTM) so they can self-regulate and provide cookieless conversion modeling. Use automatic script blocking (scanner-derived script map) for all scripts your CMP has discovered and categorized, this covers the vast majority of tracking without any HTML changes. For sites that also want to block unconsented network connections (fetch, XHR, beacons, WebSockets), enable connection-level blocking as a second enforcement layer. And enable drift detection so new trackers that appear between scans are caught and flagged automatically.

Related Guides

How to Block Scripts

Step-by-step guide to blocking tracking scripts until users give cookie consent

Google Consent Mode V2

How to implement Consent Mode V2 for Google tags via GTM

What Is a CMP?

How a Consent Management Platform helps you comply with GDPR