Key Takeaways
- Consent management platforms record what users choose. They have no mechanism to restrict what a script does once it runs in the browser.
- Nearly 50% of websites send tracking cookies to third parties before the user has interacted with the consent banner.
- 74% of top European websites and 76% of top US websites fail to honor the consent choices users actually make.
- Responsibility is shared. Platforms ship data-hungry defaults, and site owners deploy them without checking what they do.
- Third-party scripts change after deployment. A vendor update can expand what a script collects without anyone changing a setting on the site.
- Closing the gap takes runtime enforcement in the browser. Better banners and longer privacy notices leave it open.
Every organization running a website has one. A consent banner appears, the user makes a selection, and the organization records that choice as the moment it met its privacy obligations. The legal team is satisfied. The compliance dashboard shows green. The data protection officer points to the consent management platform as evidence of a functioning privacy program.
Behind that banner, dozens of third-party scripts keep executing with unrestricted access to whatever is on the page.
Consent, as most websites practice it, records what a user intended. Nothing about it controls what a script does afterward. The space between that record and the browser runtime is where most client-side data leakage happens, and no cookie banner, however well designed, was built to close it.
The Assumption the Industry Built Its Privacy Programs Around
Modern web privacy compliance rests on a simple assumption: if a user consents to data collection, the organization has met its legal obligation. The playbook follows from there. Deploy a consent management platform (CMP), configure categories such as analytics, advertising, and personalization, record the user’s selection, and load scripts conditionally based on what was accepted.
On paper, this creates a governed data flow. In practice, it creates the appearance of one.
The distance between declared consent and runtime behavior is structural. It comes from how browsers work, how third-party scripts are deployed, and how the web was built long before data protection regulation existed. CMPs were designed to meet legal requirements around disclosure and choice, and they do that job well. Restricting what a third-party script does after it starts running was never part of their design.
Most privacy programs underestimate how much that matters.
Why Consent Doesn’t Equal Control
Consider what a user is actually agreeing to when they accept a consent banner. A typical modern page loads scripts from dozens of third parties: analytics providers, advertising networks, payment processors, tag management systems, personalization engines, chatbot platforms, session replay tools, and AI-powered assistants. Each of those vendors can pull in further resources from fourth parties the organization never evaluated or approved.
The resulting execution environment looks very little like the vendor list the user saw. The banner presents a category. Behind it runs an ecosystem.
Misconfiguration explains part of the problem. The larger issue is an operating assumption that recorded consent equals governed data, and that assumption fails for technical reasons.
When a user accepts a consent category, the CMP updates its record of that choice. It has no way to reach into the browser runtime and limit what an executing script can access, and it was never designed to. Once a script loads, it operates with whatever access the browser’s Document Object Model (DOM) provides. Consent state is a piece of data the script may check if its own logic chooses to. Whether it does depends on the vendor’s code, and the organization has no external mechanism to enforce it.
Research from several independent groups shows how consistently this plays out:
- Nearly 50% of websites send at least one tracking cookie to third parties before consent. These cookies were set when the user accepted a banner on a different site, and the user’s choice on the current site never affects them. (Rasaii et al., Intractable Cookie Crumbs, PETS 2025)
- 92.6% of websites that attract tier-one advertiser spend place at least one tracker on users’ devices before gaining their consent. (Ebiquity / Cookiebot, Cookie Compliance Study)
- 74% of top websites in Europe do not honor opt-in consent as required by GDPR. (Privado, State of Website Privacy Report 2024)
- 76% of top websites in the US do not honor opt-out consent as required by CPRA. (Privado, State of Website Privacy Report 2024)
- 39% of all cookies identified on major UK websites are analytics or marketing trackers with no legitimate basis for running before consent. (ALT Agency, UK Website Health Check 2026)
Edge cases and rogue actors don’t produce numbers like these. They describe the baseline for how consent performs as a technical control across the web.
What Is Actually Happening Behind the Banner
Aggregate statistics show the scale of the problem. Specific mechanisms show how data keeps flowing even after users make deliberate privacy choices.
Jscrambler’s security research into widely deployed advertising and social media tags, often called pixels, makes the problem concrete. As documented in the Research Deep Dive: Commercial Data Collection by TikTok and Meta Pixels, these pixels were found harvesting granular customer information, including checkout interactions and product-level data, often before a user grants consent.
Take the TikTok pixel’s advanced matching capability. It scans page forms for email addresses and phone numbers, hashes them with SHA-256, and sends them to the platform. TikTok’s own developer documentation describes the feature, and it is enabled by default. Independent research by Disconnect went further, finding the pixel transmitting hashed user identifiers from pages that handle sensitive health information, including cancer patient services, fertility clinics, and prescription drug checkouts. In some cases, this happened before users finished submitting the form.
Hashing is often mistaken for anonymization. Advertising platforms maintain databases that link hashed identifiers to known accounts. When a hashed email address from a third-party website matches an entry in that database, the platform can connect the user’s activity on that site to their identity inside its own ecosystem.
The same pattern shows up in banking. Jscrambler’s Beyond the Vault research reviewed 14 financial services websites in Europe and the US and found that nine sent contact details, financial intent, or device fingerprints to third parties without a valid consent choice. Tags fired before users answered the banner. Tracking continued after users rejected cookies. On one site, a loan amount and term reached an analytics platform whatever the user chose. (Gareth Bowker, Beyond the vault: Who’s responsible for what banking sites share?, TechRadar Pro, October 2026)
Who Is Responsible for What Leaves the Page?
When researchers have raised findings like these with the platforms, the answer has been consistent: the website operator controls what gets collected. Meta has pointed to its privacy controls and its policy against sharing sensitive data. TikTok has said advertisers decide which events and parameters are sent.
That answer holds only when the operator deliberately switched collection on, and often nobody did. Bowker’s research found that Meta’s Automatic Advanced Matching is on by default and captures and hashes contact form data without a separate setup step. As Gareth Bowker writes in TechRadar Pro: “A policy against collecting sensitive data is difficult to reconcile with a feature that collects it by default.”
Website operators carry their share too. They choose the vendors, place the consent banner, and publish the cookie policy that should name every data recipient. They also deploy vendor defaults into sensitive flows, such as account opening, checkout, and loan applications, without verifying what those tags do at runtime.
Bowker’s conclusion is direct: “Both sides carry some of the blame.” Platforms ship defaults that maximize data capture, and site owners deploy them without validation. Jscrambler isn’t alleging that any provider acts in bad faith. The behavior described here matches how these tools are designed and documented to work. That is exactly the problem. When collection is the default, a vendor’s documentation and a user’s consent record can’t act as the control. The organization running the site needs its own way to see that collection and stop it.
Scripts Change After You Approve Them
Even a correct configuration has a short shelf life. Third-party vendors update their scripts on their own schedule, and the version running on a site today may behave differently from the one a privacy team reviewed last quarter.
A vendor update can quietly expand what a script can access. An organization can configure its tags and consent settings correctly at deployment and later have a script collecting more customer data than it ever approved, without anyone on its side changing a setting. The tag manager configuration looks the same, the consent banner records the same choices, and the compliance dashboard flags nothing. The data leaves anyway.
Jscrambler’s research found similar gaps at ordinary retail businesses, where customer addresses reached advertising platforms through misconfiguration, thin vendor oversight, and differences between tag manager settings and what scripts actually did at runtime. Vendor questionnaires, data maps, and records of processing describe a script at one point in time. The script keeps changing after that point.
Two Categories of Harm, One Structural Gap
Data leakage behind consent banners causes two kinds of harm. They are often treated as one, yet each calls for a different governance response.
Privacy and regulatory exposure is the more immediate concern for most compliance programs. Personal data collected before or beyond consent creates exposure under GDPR, CCPA/CPRA, HIPAA, and PCI DSS v4. That data includes names, email addresses, phone numbers, payment details, health-related search behavior, and identity attributes. The regulatory consequences are already visible: six of the twenty largest GDPR fines since 2018 relate directly to consent compliance violations on websites, including Amazon’s €746 million penalty for ad targeting without proper consent.
GDPR asks for more than a consent record. It requires appropriate technical and organizational safeguards that an organization can demonstrate. Regulators increasingly want to know which technical controls prevented data from being accessed or transmitted outside the scope of consent. Most organizations can’t answer with evidence because they have no control at the collection layer.
Competitive and strategic exposure gets less regulatory attention and, in many contexts, causes more immediate business harm. Behavioral signals from customer sessions carry real commercial value: clickstream patterns, pricing interactions, product comparisons, purchase intent, and cart values. Jscrambler’s pixel research found that third-party tags deployed for marketing and analytics routinely collect and transmit this data. In effect, a company’s proprietary customer intelligence becomes input for platforms that may also serve its competitors.
A user who accepts analytics cookies hasn’t agreed to their behavior becoming competitive intelligence for other companies. Yet the mechanism that produces this outcome sits comfortably inside what the consent framework permits, and well outside what the organization intended.
What Enforcement Actually Looks Like
Better consent banners, broader vendor contracts, and more detailed privacy notices all improve documentation. The gap described here is technical, so closing it takes technical controls that operate where data is accessed and transmitted: inside the browser, during live user sessions.
Keep a continuous inventory of scripts and the data they access. An organization can’t enforce least-privilege access to data it doesn’t know is being accessed. A meaningful client-side privacy program starts with a real-time inventory of every script executing on every page, along with the data fields each one can reach. Vendors update scripts independently, tag managers inject new ones dynamically, and a script’s scope can expand with a routine vendor update. Periodic discovery produces a picture that is out of date as soon as it’s finished.
Enforce data access at runtime. A CMP decides whether a script loads. Runtime enforcement decides what the script can do once it’s running. A script approved for analytics can’t read a payment field, access a form input before consent is recorded, or send data to an endpoint outside its authorized scope. The execution environment blocks those actions directly, so protection doesn’t depend on a vendor’s documentation or default settings.
Back compliance with behavioral evidence. Demonstrating compliance takes a record of what scripts did during live sessions: which script accessed which field, when, and where it sent the data. Consent records show what users agreed to. Behavioral telemetry shows what happened. Regulators are increasingly asking for the second, and most compliance programs can only produce the first.
Govern the full third-party execution surface. CMPs are an essential part of a privacy program. The CMP captures the user’s choice, and runtime enforcement makes sure scripts respect it. The organizations most exposed to client-side data leakage treat the CMP as the finish line for client-side privacy governance. It works far better as the starting point.
Consent is a necessary legal mechanism. On its own, it is not a security control. Organizations that treat it as one end up governing the record of what should happen while what actually happens goes ungoverned.
Frequently Asked Questions
What is the difference between a consent management platform and runtime enforcement? A consent management platform (CMP) records a user’s consent choices and gates script loading accordingly. Runtime enforcement governs what scripts do once they’re running: which DOM elements they can read, which data they can transmit, and to which endpoints. A CMP governs loading, and runtime enforcement governs execution. A complete privacy program needs both, and most organizations have only the first.
Can a script collect data even if a user clicks “Reject all”? Yes. Research consistently shows that many websites load trackers and transmit data before any consent interaction. Scripts that load before the banner appears, or that ignore consent signals because of misconfiguration or vendor defaults, operate independently of the user’s selection. Jscrambler’s banking research also found tracking that continued after users had rejected cookies.
If a pixel collects data by default, who is responsible? Both the platform and the website operator share responsibility. Platforms set the defaults, and some features, such as advanced matching, capture and hash form data without a separate setup step. Operators choose which vendors to deploy and on which pages, and they must disclose every data recipient. Whatever a platform’s defaults, operators need controls that verify and restrict what third-party tags do on their own pages at runtime.
What does PCI DSS v4 require that goes beyond consent compliance? PCI DSS v4 requirements 6.4.3 and 11.6.1 require organizations to maintain a documented inventory of all scripts on payment pages, justify the business need for each, and monitor for unauthorized changes to scripts and HTTP headers. These requirements apply to any page that could be used to capture payment card data. They call for script-level governance and tamper detection, which CMPs aren’t designed to provide.
How does client-side data leakage create competitive risk as well as privacy risk? Third-party scripts on a page can read and transmit behavioral signals, such as product views, pricing interactions, search queries, cart contents, and purchase intent, to external advertising and analytics platforms. Those platforms aggregate this data across all their publisher clients and use it to inform targeting, bidding, and optimization. An organization’s proprietary customer intelligence ends up feeding platforms that also serve its competitors, without any deliberate action on the organization’s part.
What is the first step toward runtime data governance? Visibility, because enforcement depends on it. Start with a continuous inventory of every script executing across your web properties. A point-in-time audit goes stale quickly, so the inventory should be a live feed that updates as scripts are added, modified, or start behaving differently. Without that baseline, you can’t define what authorized script behavior looks like, let alone enforce it.
See exactly which scripts on your site can access names, emails, and payment fields right now. Explore Jscrambler’s Data Governance & Privacy capabilities.
