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
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 | The scanner records observed scripts and connections for classification. Runtime gates cover supported dynamic operations; hardcoded scripts requiring prior consent need inert type, category, and data-src markup to prevent early execution or requests. |
| 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: Script and Connection Controls
CookieBeam records cookies, scripts, and network requests observed during scans. Review their purposes in the dashboard and publish the resulting classifications and rules. A scan is a snapshot of the pages visited; it cannot discover every behavior a site may perform.
Script blocking
The runtime uses the published script map and matching rules to check dynamically created scripts through browser API and DOM insertion hooks. A MutationObserver provides additional observation, but it cannot reliably prevent a browser from fetching or executing an ordinary script written directly in HTML.
For hardcoded scripts that require prior consent, keep them inert: use type="text/plain", set data-category to the intended category, and move an external URL from src to data-src. CookieBeam activates the managed script when the relevant category is allowed. Place the loader early, and test the actual page with consent denied and granted.
Connection blocking
Connection controls cover supported JavaScript transports: fetch(), XMLHttpRequest, sendBeacon, WebSocket, and EventSource. They can gate tracking bundled into an application, including a first-party endpoint with an explicit analytics or marketing classification. Same-site ownership alone does not make a reviewed tracking endpoint Necessary. Unclassified same-site requests have a compatibility allowance; explicit supported classifications are evaluated before it.
A blocked fetch receives a synthetic 204 response with an X-CookieBeam-Blocked header. The other transports use their own failure behavior. These API controls do not intercept every request a browser can make, such as all parser-created image or stylesheet loads.
Script blocking and connection blocking have separate settings. A persistent matching rule can classify both script and connection observations, while manual item overrides retain precedence. Bypass rules keep scanner evidence but exclude matched items from runtime blocking and the review queue.
Drift reporting and review
When drift reporting is enabled, the runtime can report newly observed cookies, scripts, and connections. Qualifying repeated findings can enter the inventory for review. Detection depends on which pages visitors load, the reporting settings, and what the browser runtime can observe; it is not a guarantee that every new tracker will be found.
Learning mode permits unknown scripts while the inventory is reviewed. Strict mode applies stronger blocking to eligible unknown scripts, subject to the runtime's compatibility allowances. Neither mode replaces inert markup for hardcoded scripts or a check of the site's actual consent behavior.
Consent integrations
CookieBeam provides Google Consent Mode integration and configurable regional settings. The GTM consent tag should run on Consent Initialization – All Pages, and each tracking tag needs appropriate consent settings. A consent signal is distinct from preventing every network request. Verify the browser's network and storage behavior after rejection, acceptance, and withdrawal.
1 <!-- Hardcoded external scripts use inert markup so the browser 2 cannot fetch or execute them before consent. --> 3 <script type="text/plain" data-category="analytics" 4 data-src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script> 5 6 <!-- Runtime interception supplements this pattern for scripts 7 created dynamically after CookieBeam has loaded. --> 8 9 <!-- Connection blocking (separate layer): --> 10 <!-- Even if a script runs, unconsented network requests 11 to third-party tracking endpoints are blocked: 12 fetch('https://analytics.example.com/collect') 13 -> returns Response(204, X-CookieBeam-Blocked: 1) --> 14 15 <!-- Inline scripts also require inert manual tagging --> 16 <script type="text/plain" data-category="analytics"> 17 // Inline code that should only run after consent 18 window.dataLayer = window.dataLayer || []; 19 </script> 20 21 <!-- Cleanup script: runs when user REVOKES consent --> 22 <script type="text/plain" data-category="!analytics"> 23 window['ga-disable-G-XXXXXXX'] = true; 24 </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
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.