Session recording tools are standard equipment in the iGaming operator's analytics stack. Hotjar, FullStory, and Microsoft Clarity are used daily by UX and CRO teams to understand player journeys, identify friction in registration flows, and optimise deposit funnels. Most compliance teams approved these tools when they were first onboarded. What compliance teams are not routinely reviewing is what those tools are doing now, who controls the code that runs under their name, and whether any of that code has been modified since the original approval. The IBM 2024 Cost of a Data Breach report puts the global average breach cost at $4.88 million. For a licensed gambling operator, add the regulatory dimension and the figure climbs further still.
What Session Recording Tools Actually Collect on Gambling Sites
Quick Answer: Session recording tools on gambling sites collect far more sensitive data than on typical e-commerce sites. Player email addresses, phone numbers, deposit amounts, withdrawal patterns, and session tokens are all potentially within recording scope. The higher-risk data profile of gambling users makes any exfiltration incident significantly more serious than a standard consumer data breach.
On a generic retail website, a misconfigured session recorder can capture a user's name and delivery address. On a gambling site, the recording tool can access more sensitive data.
During a typical player session, a session recording tool running with broad DOM access can observe:
- Email addresses and phone numbers entered during registration or account verification
- Date of birth and identity document details submitted for KYC
- Deposit amounts, payment method selections, and withdrawal requests
- Betting history and stake values visible in the player account dashboard
- Session token values present in page URLs or form fields
- Responses to responsible gambling prompts and self-exclusion disclosures
Under GDPR Article 4, all of the above constitutes personal data. Financial behaviour, health-adjacent data (responsible gambling status), and identity verification data all carry elevated protection requirements. For gambling operators subject to UK ICO jurisdiction, the British Airways enforcement precedent is directly relevant: the ICO issued a £20 million penalty following a breach that exposed passenger payment and personal data through a compromised third-party script injected into the booking flow.
The gambling context amplifies the risk in two specific ways. First, gambling operators hold data on player financial vulnerability that carries particular sensitivity under GDPR's proportionality and data minimisation requirements. Second, gambling licences in the UK, Malta, and other jurisdictions impose independent data protection obligations that can compound GDPR penalties with licence-level sanctions.
Three Ways Session Recording Tools Go Wrong
Quick Answer: Session recording tools fail in three distinct ways: misconfiguration that exposes PII fields the tool was never intended to capture; monkey-patching, where injected code wraps the legitimate recorder to intercept its data stream; and shadow recording tools injected through GTM or affiliate scripts without any operator authorisation. Standard security controls catch none of these reliably.
Misconfiguration: the tool is legitimate, the configuration is not
Session recording vendors provide masking controls intended to exclude sensitive form fields from capture. In practice, these controls are applied inconsistently. A configuration change made during a registration flow redesign can accidentally unmask fields that were previously excluded. A new page added to the deposit funnel may not have inherited the masking rules applied to the original pages.
The tool itself is doing exactly what it is configured to do. The configuration is the problem, and most compliance teams do not have visibility into session recording configuration at the field level.
Monkey-patching: the tool is legitimate, the code is not
Monkey-patching is a specific JavaScript technique where an injected script wraps or replaces a function in a legitimately loaded library. In the context of session recording tools, this means a malicious script loaded via GTM, an affiliate pixel, or any other third-party vector can intercept the data stream flowing through Hotjar or FullStory without the recording tool's knowledge or any visible change to the tool's behaviour.
From the outside, Hotjar is still running. The consent banner correctly identifies Hotjar. The cookies placed by Hotjar are present. Nothing in standard monitoring or audit tooling flags an anomaly. But the data being recorded is no longer going only to Hotjar's servers: an intermediate function is copying it to a third-party endpoint before it reaches Hotjar.
This is a technically sophisticated attack, but it requires only the ability to inject a small JavaScript fragment into the page, which any GTM container with sufficient permissions can do.
Shadow recording tools: the tool was never authorised
The third failure mode requires no modification of any legitimate tool. A marketing team adds a third-party analytics or heatmap script via GTM, believing it to be a standard UX tool. The script includes session recording functionality that was not disclosed in the tool's documentation or was added to the tool after the initial evaluation. Alternatively, a compromised affiliate script loads a session recorder as a secondary payload.
In either case, the operator's consent management platform has granted consent for a named list of tools. The undisclosed recorder is not on that list. Consent for Hotjar does not extend to an unrelated session recorder loaded by a script that was trusted because it appeared to be something else.
cside detected more than 300,000 attack signals across monitored sites in Q1 2025, and a significant category of these involves scripts making data requests to endpoints that were not part of any approved vendor integration.
Why Cookie Consent Tooling Does Not Catch This
Quick Answer: Cookie consent management platforms operate on the assumption that named, consented tools behave as described at the time of consent. They cannot detect a compromised version of a consented tool, a function intercepted by an injected script, or a shadow tool loaded as a secondary payload. Consent is granted to a tool name, not to a specific binary.
This is the fundamental gap that compliance teams often discover too late. Cookie consent platforms like OneTrust, TrustArc, or Cookiebot maintain a list of approved vendors. When a user consents to analytics cookies, consent is extended to the tools on that list. The consent management platform has no mechanism to verify that the JavaScript running under Hotjar's name is the same code that was evaluated when Hotjar was approved.
The lawful basis for processing collected by session recording tools in the gambling context is typically consent under GDPR Article 6(1)(a). That consent is specific: it covers the data collected by Hotjar, as described to the user. It does not cover a monkey-patched version of Hotjar intercepting the same data stream. It does not cover a shadow recorder loaded alongside Hotjar without disclosure.
Under GDPR Article 5's data minimisation principle, operators are responsible for ensuring that personal data is not processed beyond what is necessary for the stated purpose. A session recording tool that is capturing financial data beyond its disclosed scope, whether through misconfiguration or compromise, is processing data outside the consented purpose. The operator is the controller. The liability sits with the operator, not the recording tool vendor.
GDPR Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach. If an operator has no visibility into what its session recording tools are actually capturing and transmitting, it cannot be aware of a breach until after significant damage has occurred. The ICO's British Airways enforcement action, which resulted in a £20 million penalty, involved precisely this pattern: a third-party script compromise that went undetected because the operator had no runtime visibility into what scripts on its booking page were actually doing.
How cside Detects Anomalous Session Recorder Behaviour
Quick Answer: cside instruments every real user session in the browser, observing what each script actually executes at runtime. For session recording tools, this means detecting new API endpoints called by the recording script, changed data destinations, expanded recording scope on pages not previously covered, and secondary payloads loaded by the recording tool itself. These signals are available in real time, not after the fact.
The detection approach cside uses for session recording tool anomalies is different from anything consent management or network-level monitoring provides. Because cside runs inside the browser on every session, it observes what each script actually does, not merely whether it is present.
For session recording tools specifically, the signals cside monitors include:
- New outbound network requests from a known recording tool: If Hotjar, which has historically called only hog.is endpoints, suddenly begins making requests to an unfamiliar domain, that is a high-priority alert.
- Changed data destination: A recording tool that was previously sending data to a known vendor endpoint and now routes to a different IP or domain, even if the domain appears plausible, triggers an alert.
- Modified recording scope: If a session recording tool begins capturing form field values on pages where it previously masked them, the behavioural change is observable at the execution level.
- Secondary script loading: If a session recording tool begins loading additional scripts that were not previously associated with it, this is an indicator of monkey-patching or supply chain compromise affecting the tool itself.
- New scripts making recording-like API calls: A script not previously classified as a session recorder that begins making calls consistent with DOM capture and data exfiltration is surfaced as an unrecognised tool with high-risk behaviour.
Beyond detection, cside's per-vendor permission profiles give operators direct control over what session recording tools are allowed to do. Operators can block a session recording vendor from accessing password fields, payment form fields, or the Payment Request API at the browser layer. This restriction is enforced even if the vendor's code is subsequently compromised: a hijacked session recorder cannot reach fields it has been denied permission to access, regardless of what malicious code is injected into it.
This runtime behavioural approach means the detection is not dependent on knowing in advance that a specific tool has been compromised. Anomalous behaviour is flagged when it occurs, not when a threat intelligence feed publishes a rule about a known compromise.
For compliance teams at licensed iGaming operators, the practical value is the ability to demonstrate ongoing monitoring of personal data processing by third-party tools. This is directly relevant to accountability obligations under GDPR Article 5(2) and to the data protection by design requirements in Article 25. Documentation of active monitoring is a material factor in how supervisory authorities assess proportionality of penalties when incidents do occur.
What We Found in One UK Operator's Session Recording Stack
In deploying cside at a UK-licensed online casino earlier this year, the compliance team's initial concern was straightforward: they wanted to confirm that Hotjar was correctly masking form fields on the deposit page. What the session-level telemetry surfaced went further. Within the first 48 hours of browser-layer monitoring, cside identified a second recording tool firing on the registration and deposit pages that the operator had no record of. The tool was not declared in the consent management platform, not in the operator's vendor list, and not in any DPA the compliance team had on file.
Tracing the script origin identified an affiliate tracking snippet added to the GTM container eight months earlier. Buried in a dependent script loaded by that affiliate tag was a session recorder, not the affiliate's primary product but an analytics add-on that had been included in a minor version update of the affiliate's JavaScript SDK. The recorder had been sending session events, including partially visible form field values, to an endpoint the operator did not recognise for the entire eight-month period.
The compliance team initiated an Article 33 assessment within 24 hours of identification. The cside session logs provided the exact first-occurrence timestamp, the number of affected sessions, and the destination endpoint, which allowed the DPO to scope the notification accurately rather than estimating. The affiliate script was removed, the vendor was notified, and the operator updated their script governance process to require explicit review of any affiliate SDK update before deployment. The monitoring that surfaced the issue then became the evidence trail for the breach assessment.
Summary
Session recording tools carry a higher risk profile on gambling sites than on most other web properties because of the sensitivity of the data accessible during player sessions: KYC documents, financial transaction data, responsible gambling disclosures. The three failure modes, misconfiguration, monkey-patching, and shadow recorders, are each capable of exposing that data without triggering any alert in conventional security monitoring. Cookie consent platforms manage what they are told about, not what is actually executing. Network-layer tools see that Hotjar loaded, not what it sent or what intercepted its data stream. The only detection layer that operates at the level of the attack is one that instruments the browser's execution environment directly, across every session, and flags behavioural deviations in real time. cside's Privacy Watch provides that runtime visibility into what session recording tools are actually capturing and transmitting, while its client-side security capability addresses the supply chain and injection vectors that consent and network tools cannot reach.
