GDPR and Online Gambling: Why Unauthorised Pixels Create a Dual Liability Problem

The most common response I hear from DPOs when the subject of unauthorised pixels comes up is: "we have a CMP, so we're covered." In practice, a consent management platform only covers the tools that have been declared to it. When we deploy cside at a licensed operator, we routinely find pixel fires that the CMP has no record of, often because they arrived through an affiliate script or a GTM container configuration that predates the current compliance stack. The DPO typically discovers this is happening when we show them a live session trace, not before.

Licensed gambling operators cannot advertise on Facebook, TikTok, Instagram, or LinkedIn. The advertising policies of all four platforms prohibit gambling promotions without explicit platform approval, and that approval is rarely granted. What most operators have not fully modelled is what happens when a pixel from one of these platforms appears on their site without their knowledge. It happens more often than compliance teams realise: in Q1 2025, cside detected over 300,000 attack signals across monitored gambling and e-commerce sites (each representing a distinct anomalous behaviour observed in a real player session), with unauthorised pixel fires among the most common findings. When it does happen, the operator faces two simultaneous problems that compound each other in ways that are difficult to resolve quickly.

How Unauthorised Pixels Get Onto Gambling Sites Without Operator Knowledge

Quick Answer: Unauthorised tracking pixels reach gambling platforms through four primary vectors: compromised affiliate scripts that inject code without the operator's knowledge, shadow Google Tag Manager containers configured by marketing teams without security review, misconfigured consent management platforms that load tags outside their intended scope, and supply chain compromises affecting upstream JavaScript libraries used across thousands of sites simultaneously.

The assumption most operators make is that pixels are things they install deliberately. In practice, the more common scenario is that a pixel arrives through an indirect route and goes undetected because the operator has no runtime visibility into what is executing in player browsers.

The four main vectors are:

• Affiliate scripts: affiliate partners are given tracking code that operators load on their sites. When an affiliate's script is compromised or an affiliate deliberately injects additional pixels, the operator's platform carries the pixel without having installed it
• Shadow GTM containers: marketing teams frequently create additional Google Tag Manager containers or add tags to existing ones without going through a security review. A pixel installed by a contractor six months ago may still be firing in production
• Consent management misconfiguration: CMPs manage consent for tools that are declared within the consent flow. Tags that are added to a GTM container after the CMP was configured, or loaded outside the consent layer entirely, are not covered by the consent mechanism
• Supply chain compromise: the Polyfill.js supply chain attack in June 2024 affected over 100,000 sites simultaneously through a single library takeover. A similar attack targeting a widely-used analytics or affiliate library could inject pixels across an entire sector without any operator taking a deliberate action

The common factor in all four vectors is that the pixel fires without the operator knowing. Players' data is sent to Facebook, TikTok, or LinkedIn. The operator is liable.

The GDPR Liability: What Articles 5, 28, and 33 Mean for Pixel Fires

Quick Answer: Under GDPR Article 5, player data must be processed lawfully, fairly, and with a valid legal basis. An unauthorised pixel transmitting player data to a social media platform has no lawful basis. Under Article 28, the operator is the data controller responsible for that processing. Under Article 33, if the pixel fire constitutes a data breach, the operator has 72 hours to notify the supervisory authority, regardless of whether they installed the pixel.

GDPR does not offer an "I didn't know about it" defence for data controllers. The regulation establishes accountability as a foundational principle: operators are responsible for demonstrating that all processing of personal data on their platforms is lawful, documented, and controlled.

Applying this to an unauthorised pixel scenario:

Article 5 requires that personal data be processed lawfully and for specified, explicit, and legitimate purposes. A pixel transmitting player data to Facebook serves Facebook's advertising optimisation purposes, not the operator's legitimate interests as a licensed gambling operator. There is no plausible legal basis for that transfer. Consent cannot be relied upon because the pixel is not in the consent flow. Legitimate interest cannot be relied upon because the operator did not know the pixel was there and cannot have assessed its proportionality.

Article 28 makes the operator a data controller responsible for ensuring that any third party processing data on their platform has a documented Data Processing Agreement in place. There is no DPA covering an unauthorised pixel. The structural breach exists independently of the harm caused.

Article 33 requires notification to the supervisory authority within 72 hours of the operator becoming aware of a personal data breach. Whether an unauthorised pixel constitutes a breach depends on whether it resulted in personal data being transmitted without authorisation, and the answer in most cases is yes. The UK ICO's £20M penalty against British Airways provides the clearest precedent: third-party scripts harvesting customer data from a company's website were found to be the company's liability, and the failure to detect and prevent the harvesting was itself the regulatory failure.

The Advertising Policy Liability: Why Platform Penalties Compound the Problem

Quick Answer: Facebook, TikTok, Instagram, and LinkedIn prohibit gambling advertising under their platform policies. When a pixel from any of these platforms fires on a gambling site, it creates an activity record linking the gambling domain to the platform account. Even if the operator has never deliberately advertised on these platforms, the pixel activity can be detected and used as grounds for suspending the operator's ad accounts, blacklisting their domain, or triggering a policy review.

This is the second, often overlooked, dimension of the dual liability problem. GDPR enforcement is the more widely discussed risk. The advertising policy risk is more immediate and can have direct commercial consequences.

The mechanics of the risk are as follows. When a pixel fires on a gambling site, it sends an event to the associated advertising account. If that account belongs to the gambling operator, even if it has never been used for gambling advertising, the platform can detect the pixel placement on a gambling domain. This may result in:

• Suspension of the advertising account associated with the pixel
• Domain-level blacklisting that prevents future use of the platform by the operator or their affiliates
• Policy review that affects other products or accounts linked to the same business entity
• Use of the pixel activity as evidence in platform policy enforcement proceedings

If the pixel does not belong to the operator, the risk profile shifts: the pixel belongs to an affiliate, a compromised vendor, or an unknown third party. In this scenario, the operator's GDPR liability is the same (they are responsible for all processing on their domain) but the advertising policy risk may be directed elsewhere. However, the operator's domain is now associated with pixel activity from an account they cannot control, which creates its own complications.

The compounding problem is that both liabilities surface simultaneously. While the compliance team is managing the GDPR breach notification and ICO engagement, the marketing team is discovering that ad accounts are suspended or domains are flagged. Resolving one does not resolve the other, and the processes for doing so involve different regulators, different timelines, and different internal stakeholders.

Why Consent Management Platforms Do Not Catch This

Quick Answer: Consent management platforms manage consent for the tools that are declared within the consent layer. They do not detect or block scripts that are injected outside the consent flow, added to tag management containers after CMP configuration, or loaded through compromised vendor scripts. A pixel that arrives through a supply chain compromise or an undeclared GTM tag will fire regardless of whether the player gave consent for anything.

This is a critical misconception in how many compliance teams think about their data processing obligations. A CMP is a consent interface, not a script inventory or a runtime monitor. It can only manage what has been declared to it.

A CMP will not catch:

• Pixels injected by a compromised affiliate script that loads independently of the consent layer
• Tags added to a GTM container by a team member who did not update the CMP configuration
• Scripts that activate conditionally, for example, for players in certain geographic regions, at certain times of day, or after specific actions
• Supply chain compromises in upstream libraries that inject pixel code at runtime without modifying the host script's URL or file hash

The Polyfill.js compromise is instructive here. The attack modified the behaviour of a JavaScript library that was already loaded, permitted, and in some cases declared in the consent layer. No CMP would have flagged it because the script's origin and declared function had not changed. The malicious behaviour was added at runtime by the compromised version of the library.

For gambling operators, where any unauthorised data processing creates both GDPR and advertising policy risk, a CMP alone is not sufficient. The question is not just "did the player consent to this tool?" but "is this tool doing only what it was declared to do, and is it the only tool running in this session?"

How cside Detects Every Pixel Firing and Maps It to Its Data Destination

Quick Answer: cside instruments 100% of real player sessions in the browser and observes every network request made by every script executing on the page. It detects pixel fires, including those from Facebook, TikTok, LinkedIn, and other platforms, regardless of whether they appear in the consent flow, the tag management system, or the operator's script inventory. Every pixel fire is mapped to its destination, timestamped, and logged for compliance evidence.

The challenge with unauthorised pixels is that they are designed not to be noticed. They are a few lines of JavaScript that make an outbound network request. Without runtime monitoring, they are invisible.

cside addresses this by instrumenting the execution layer:

• Every script loading on player-facing pages is identified in real sessions, including those loaded dynamically, conditionally, or through nested script calls
• Every outbound network request is captured and mapped to its destination, including pixel endpoints for Facebook (facebook.com/tr), TikTok (analytics.tiktok.com), LinkedIn (px.ads.linkedin.com), and others
• Pixel fires are cross-referenced against the operator's declared consent configuration to identify fires that occur outside the consent flow or from sources not in the script inventory
• Alerts are triggered for each undeclared pixel fire with session context, timestamp, and destination mapping
• Per-vendor permission profiles let operators block the Payment Request API and cookie write access for pixel and analytics vendors at the browser layer; this enforcement holds even if the vendor's code is later compromised, so a hijacked analytics script cannot access payment fields or set tracking cookies regardless of what its code attempts

This provides DPOs and compliance teams with the evidence they need to demonstrate that monitoring is in place, to investigate incidents when they occur, and to produce documentation for ICO inquiries or supervisory authority breach notifications.

Unlike network-layer tools, which monitor traffic at the perimeter but cannot see the context in which a pixel fired, or CMPs, which manage declared tools but cannot detect undeclared ones, cside operates where the data is actually processed: inside the browser, in the player's session.

In one deployment at an EU-licensed iGaming operator (operator details anonymised), cside detected a TikTok pixel firing on the operator's registration and deposit confirmation pages. The pixel had been injected by an affiliate partner script that was loaded conditionally for players referred through a specific traffic source. The operator's CMP had no record of it. The pixel had been firing for an unknown period. Once identified, the operator was able to isolate the affiliate script, calculate the scope of data transmitted, and produce a preliminary notification assessment for their supervisory authority within 24 hours. That turnaround was only achievable because the cside session logs provided a precise record of when the pixel first appeared and how many sessions it had affected.

For operators managing the dual liability risk of GDPR enforcement and advertising platform penalties, real-time pixel detection is the mechanism that reduces both the probability of undetected exposure and the time-to-awareness when an incident does occur.

What to Do Next

If your organisation holds a gambling licence and you do not currently have runtime monitoring of pixel activity in player sessions, the starting point is understanding what is actually firing. cside's Privacy Watch provides a complete pixel inventory from real player sessions, cross-referenced against your consent configuration, with alerts for every undeclared destination. For DPOs managing breach notification obligations under GDPR Article 33, the session logs cside generates are the foundation for a credible supervisory authority submission. The client-side security capability addresses the upstream compromise vectors that CMPs and network tools cannot reach.