In 2024, IBM's Cost of a Data Breach report put the global average breach cost at $4.88M, a figure that does not include regulatory fines, licence suspension risk, or the player trust damage that follows a disclosed incident. For licensed gambling operators, those secondary costs can exceed the primary breach figure. Yet many operators are running client-side security tools that were designed to satisfy audit requirements, not to detect live attacks: tools that sample fewer than 10% of user sessions and treat what they do not see as low-risk. That assumption fails structurally when attackers design their payloads to target the 90% that goes unmonitored.
How Session Sampling Works and Why It Was Built for Compliance
Quick Answer: Session sampling in client-side security tools means the tool instruments a randomly selected percentage of user sessions, typically between 1% and 10%, and infers overall site behaviour from that sample. This approach was designed to satisfy audit requirements at low infrastructure cost, not to detect attacks that may occur in only a small fraction of sessions or be deliberately targeted at unmonitored users.
Sampling is a pragmatic engineering choice when the goal is reporting. If an operator needs to demonstrate to an auditor that their payment pages load only approved scripts, sampling a statistically representative set of sessions can produce that evidence at a fraction of the infrastructure cost of monitoring every session.
The problem is that security is not the same problem as auditing. An audit asks: "Is this site generally behaving correctly?" A security question asks: "Is anything behaving maliciously right now?" These require fundamentally different detection architectures.
When a client-side security tool samples 10% of sessions, it is making a silent bet: that any attack affecting the site will be evenly distributed across all sessions and therefore statistically visible in the sample. That bet is wrong for the specific attack patterns that target gambling platforms.
Gambling Attack Patterns That Sampling Cannot Detect
Quick Answer: Attacks on gambling platforms are frequently designed to be low-volume, targeted, and time-limited. Geo-targeted redirects affect only players from specific countries. VIP player attacks trigger on specific account balances or session lengths. Time-limited bonus manipulation scripts run only during promotional windows. A 10% sampling rate will miss these by design, not by accident.
The ENISA Threat Landscape for Supply Chain Attacks identifies targeted, low-prevalence attacks as the most difficult to detect with conventional monitoring. In the gambling context, that threat model maps precisely to how client-side attacks are actually executed.
Geo-targeted redirects. An attacker who has compromised a third-party script on a gambling platform can configure the payload to execute only for players in specific countries, for example redirecting players from a grey-market jurisdiction to a competing unlicensed operator. If only 10% of sessions are monitored and geo-filtered attacks affect 5% of sessions in a single country, the probability of the attack appearing in the monitored sample drops to near zero.
VIP player targeting. High-value players represent a disproportionate share of gross gaming revenue. Attack payloads can be configured to trigger on account balance thresholds, session length, or deposit history, all of which are readable from the DOM on most casino sites. A script that activates only when a player's visible balance exceeds a certain threshold is explicitly designed to be invisible to sampling-based tools.
Time-limited bonus manipulation. Promotional periods (welcome bonuses, free spin windows, seasonal campaigns) are the highest-traffic and highest-value periods in a casino's calendar. A script that modifies bonus eligibility checks or redirects players to a competing platform's mirrored offer runs its attack during a defined window and removes itself when the promotion ends. A sampling tool that was not active during every session in that window has no record of the event.
Deposit flow interception. Scripts that activate only when a player reaches a specific step in the deposit funnel (card entry, 3DS confirmation, wallet selection) are designed to execute in a short window that sampling tools may never observe, particularly if the attack is also geo-filtered.
The Compliance vs. Security Gap
Quick Answer: Passing a PCI DSS or regulatory compliance audit is not the same as detecting live attacks. Audit-oriented tools prove that your site configuration meets a standard at a point in time. Security-oriented tools detect when behaviour deviates from that standard in real time. For gambling operators, the compliance gap is a business risk: an operator can pass every audit and still have a live attack running in the sessions the tool does not monitor.
The PCI Security Standards Council updated PCI DSS requirement 6.4.3 to require explicit inventory and monitoring of all scripts on payment pages. But the standard specifies monitoring, and it does not specify that 100% of sessions must be covered. A tool that samples 10% and produces a clean audit report satisfies the letter of the requirement while leaving the security gap intact.
This is not a hypothetical concern. The UK ICO's £20M penalty against British Airways followed a client-side script compromise that went undetected for months. The tool that was in place was logging network requests, not monitoring script execution behaviour across 100% of sessions in the browser itself.
For operators licensed under the UK Gambling Commission, client-side security posture is now part of technical compliance assessments. An operator who can demonstrate continuous 100% session monitoring is in a materially stronger position than one who demonstrates periodic sampled audits, particularly if a player complaint or regulatory inquiry requires evidence of what a script was doing in a specific session.
The gap between compliance and security is also a gap in incident response capability. When an attack is eventually discovered, whether through a player complaint, a chargeback spike, or an external disclosure, the operator needs to answer: "When did this start? Which sessions were affected?" A sampling tool cannot answer that question. A tool that covers every session can.
cside's 100% Session Coverage Model
Quick Answer: cside instruments every real user session in the browser itself, without sampling. Every script that executes, every network request it initiates, and every DOM mutation it makes is observed across 100% of traffic. This is not optional coverage. It is the baseline, because targeted attacks are designed to survive in the sessions that sampling tools never see.
cside's architecture is built around the principle that you cannot detect what you do not observe. Instrumenting 100% of sessions is not a premium feature. It is the prerequisite for the product to function as a security tool rather than a compliance reporting tool. Equally important is what drives the detection: an AI-powered behavioural engine that watches what each script does in real time, examining what data it accesses, where it sends that data, and whether its behaviour matches known breach patterns. This is not signature matching against a list of known-bad scripts. It is real-time behavioural analysis across every session, which is how attacks that have never been seen before can still be detected.
The practical difference for a gambling operator is measurable. cside's telemetry from Q1 2025 identified over 300,000 attack signals across monitored sites in a single quarter. The majority of those signals would not have appeared in a 10% sampled dataset with statistical regularity. Many were low-volume, targeted, or time-limited events of exactly the type that sampling-based tools are structurally unable to surface.
The 100% coverage model also enables accurate incident scoping. When cside identifies a malicious script behaviour, it can report precisely which sessions were affected, during which time window, and what the script did in each case. That capability is critical for:
- Notifying affected players within GDPR's 72-hour breach notification window
- Responding to regulatory inquiries with session-level evidence
- Quantifying chargeback and fraud exposure from specific attack windows
- Terminating affiliate relationships with supporting data, not just suspicions
To illustrate the difference: when cside was deployed by a licensed iGaming operator in 2025, the first 30 days of 100% session instrumentation surfaced anomalous script behaviour in a cohort of VIP deposit sessions that represented under 4% of total traffic. The operator's previous compliance tool, which sampled 10% of sessions, had produced clean audit reports for months. The sessions the sampling tool had been reviewing did not overlap meaningfully with the affected cohort. The behaviour cside flagged turned out to be a compromised third-party analytics script that had been reading account balance values from the DOM during deposit flows. The operator had been operating blind to that behaviour for the entirety of the prior tool's tenure.
Cloudflare Page Shield provides a network-layer view of which scripts load on a page. That is a useful inventory tool, but it does not observe what those scripts do at runtime inside the browser. It monitors network requests, not script execution behaviour. The distinction matters: a script that reads a cookie, modifies a DOM field, and initiates a redirect performs all three actions before making any network request that Page Shield would observe. This is the same blind spot that lets compromised affiliate scripts steal casino revenue and malicious browser extensions target casino players run without tripping a network-layer control.
How to Evaluate Whether Your Current Tool Samples
Quick Answer: Ask your current vendor directly: what percentage of user sessions does your tool instrument? If the answer is anything below 100%, or if the answer involves statistical inference from a sample, the tool is not providing security coverage for the sessions it does not see. Request documentation of the sampling methodology and ask how the tool would detect a geo-targeted attack affecting 3% of sessions.
Evaluating sampling behaviour is not always straightforward because vendors do not always lead with this information. The following questions will surface it:
- "What percentage of our user sessions does your tool actively instrument?"
- "If a script change only executes for logged-in players in the UK during a 48-hour window, would your tool detect it?"
- "Can you provide session-level evidence of a specific script execution event in a specific user session?"
- "How does your sampling rate affect your ability to detect geo-targeted or VIP-targeted attacks?"
If a vendor cannot answer the third question (providing session-level evidence for a specific session), they are not instrumenting individual sessions. They are aggregating behaviour across a sampled population, which is a compliance reporting architecture, not a security detection architecture.
The Verizon 2024 DBIR identifies web applications as the leading attack vector in external breaches. For gambling operators, the attack is increasingly happening at the client-side layer (the browser itself), and the question is whether the monitoring tool is operating at the same layer, on every session, or whether it is producing audit reports while attacks run unobserved in the sessions it never saw.
The Bottom Line for Licensed Gambling Operators
Session sampling is an audit architecture. It was designed to answer the question "is our site generally configured correctly?" at low infrastructure cost. It was not designed to answer "what is happening to our players right now, in this session, on this page?"
For a licensed gambling operator, those are different questions with different stakes. Compliance audit failures carry regulatory risk. Live attacks on player sessions carry regulatory risk, player harm, chargeback exposure, and reputational damage that audits cannot retroactively prevent.
The path to closing the gap is not to run audits more frequently. It is to instrument every session, baseline every script's normal behaviour, and receive alerts when that behaviour changes in any session, regardless of how targeted or low-volume the attack is. That is what 100% session coverage means in practice.
If you would like to see cside's approach compared directly against your current tooling, including how it would have covered sessions your present tool has not seen, request a coverage comparison from the cside team.
