The Script Outside the Core: Who Controls an Operator’s Third-Party Code?

By iGaming Review · Published 5 November 2026

Business · Analysis · 5 November 2026

By iGaming Review

Polymarket’s October security incident exposes a commercial question behind browser security: who can change a customer-facing service, who can stop it, and who pays when the emergency stop itself causes losses?

A performance-monitoring tool should help a business understand whether its service works. At Polymarket on 29 October, a compromised supplier script instead became a route into some customers’ active sessions. According to the platform’s subsequent incident report, attackers used it to sell positions and move funds from wallets. ¹

The relevance for gambling operators extends beyond prediction markets. A service bought for one purpose can acquire a very different significance when its code runs inside a page where customers are already authenticated. The question is how much authority that service actually has—and whether anyone has responsibility for the whole chain from supplier selection to customer redress.

That chain includes an uncomfortable trade-off. Stopping an attack can also stop customers from managing positions whose value continues to change. Security, trading operations and compensation policy therefore meet at the same decision.

A supplier label does not define its access

The OWASP guidance on third-party JavaScript identifies three connected risks: losing control over changes to an application, allowing arbitrary code to execute in a customer’s browser, and exposing information to another party. A hosted script can change after the operator has reviewed its original version. A tag manager can also introduce additional suppliers through a configuration change rather than an ordinary application release. ²

This makes the procurement description an unreliable guide to technical importance. “Analytics”, “customer support” and “performance monitoring” describe intended functions. They do not establish what code can read or do after deployment.

For an operator, the useful inventory is consequently more demanding than a list of contracts. It connects each external component to the pages where it appears, the information available there, the permissions it receives and the people who can alter its configuration. A supplier used on a public information page deserves a different assessment from the same supplier embedded in an authenticated account journey.

This is an analysis of risk, not a claim that all external scripts can withdraw funds. The consequences depend on the application’s architecture and controls. It is precisely that variation which makes a generic “third-party approved” label insufficient.

The browser is part of the service

Britain’s Gambling Commission already defines the security perimeter more broadly than the central gambling engine. Its remote technical standards cover systems handling sensitive customer information, balances and the state of a gamble, together with their entry and exit points and relevant communications networks. The listed controls include supplier relationships, supplier-service changes, incident preparation and evidence collection. ³

These are requirements for the licensees within that framework. They should not be read as a finding that Polymarket breached British gambling rules; its incident is used here as a technical and operational case study, not as a jurisdictional comparison.

The practical implication for a licensed operator is to follow the customer journey across organisational boundaries. A front-end service can be important because it communicates with a critical system, even when it is purchased by another department and appears on a different supplier budget.

Historical evidence shows why that distinction matters. In its 2020 Ticketmaster penalty notice, the Information Commissioner examined the deployment of a third-party chatbot on payment pages and found shortcomings in the assessment of that risk. The notice also records Ticketmaster’s explanation that the chatbot was a support tool, not intended to process card data. Intended purpose and exposure were separate questions. ⁴

The comparison does not establish an identical mechanism or legal outcome. It illustrates a recurring assessment problem: asking what a component was bought to do without also asking what its position in the customer journey permits it to affect.

What happens between annual audits?

For the relevant British remote licence categories, the Gambling Commission requires an annual independent security audit against the RTS security requirements, based on specified ISO/IEC 27001 controls. It does not approve firms for this work: the licensee must select a reputable, suitably qualified and independent auditor. ⁵

The Commission’s audit advice requires the operator and auditor to assess third-party coverage by function and access to critical information or systems. A supplier’s own audit does not, by itself, discharge the operator’s responsibility to obtain adequate assurance. The report should identify the systems reviewed and the evidence supporting its conclusions. ⁶

The management question is therefore more precise than whether the platform passed an audit: which externally supplied scripts, access paths and change controls did the work cover? If a remotely hosted script changes afterwards, what detects the change, who authorises continued use, and what triggers fresh review? A periodic audit is not continuous verification of every script version served to customers. These are proposed governance questions, not evidence that any particular audit missed an external component.

Approval needs a technical boundary

Several controls address different parts of that problem. They are not interchangeable.

Subresource Integrity allows a browser to compare a downloaded resource with an expected cryptographic hash. If the content does not match, the browser refuses to execute it. That can prevent an altered file from being silently accepted, but it does not establish that the approved version is safe. An update also needs a corresponding, controlled approval process. ⁷

A Content Security Policy can restrict which resources a page loads and what certain kinds of code may do. A policy that simply trusts a supplier’s domain does not, by itself, establish that every script served from that domain is the reviewed version. The content of the policy matters as much as its presence. ⁸

Isolation and reducing what data a component receives address another question: what remains exposed if a permitted component misbehaves? OWASP discusses containment and server-side approaches among the available options. Their suitability depends on the service being delivered. ²

For management, the choice is not simply whether to buy another security product. It is whether a useful feature warrants the access it requires—and whether that access can be reduced without losing the function. A monitoring tool that needs a narrow set of performance measurements should prompt an explicit discussion if its deployment gives it a much wider view of an account page.

Payment compliance has a defined scope

Card-payment standards provide a useful example of more specific responsibility. PCI Security Standards Council FAQ 1588 explains the script-related eligibility criterion for SAQ A merchants using an embedded third-party payment page or form. It describes protection techniques or confirmation from the compliant payment provider that its correctly implemented solution protects against script attacks. ⁹

The same FAQ distinguishes embedded payment forms from redirect arrangements and fully outsourced payment functions. It also tells merchants to confirm the appropriate assessment with the entity accepting their compliance submission. A statement that an operator “uses a payment provider” therefore does not answer how its particular payment journey is protected.

Equally, that payment-specific guidance cannot certify the safety of an entire betting or trading interface. Operators need to establish the scope of each assurance before treating it as evidence about another part of the customer experience.

The emergency stop has an economic consequence

Polymarket says it removed the compromised script, cleared caches, paused trading and its relayer, and reset active sessions. Its 30 October postmortem described further integrity controls and monitoring. It also said it was returning $3.9 million to traders: $2.7 million plus $1.2 million for pause-related losses. Those are the company’s reported figures, not an independently audited loss calculation. ¹

The second amount changes the discussion. Recovery has to consider both unauthorised activity and customers affected by protective action. A platform might successfully contain an incident while still facing difficult decisions about customers who could not act during the interruption.

The record needed for that decision is broader than a list of compromised accounts. Depending on the product and the compensation approach, it may include which positions existed when a pause began, what happened to their underlying events, which instructions were accepted and when service resumed. These are operational questions for the incident plan, not assumptions that every gambling product should copy Polymarket’s refund model.

NIST’s current incident-response guidance places preparation, detection, response and recovery within continuing cybersecurity risk management. That is a useful organising principle here: the financial and customer-service consequences belong in planning before a security team needs the stop button. ¹⁰

An availability promise is not a loss guarantee

Regulatory responsibility and contractual recovery are separate questions. The Gambling Commission’s third-party responsibility provision makes licensees responsible for contracted activities related to their licensed business and requires relevant contractual terms on compliance, information and termination. It does not determine who ultimately bears every commercial loss. ¹¹

Published monitoring-service terms illustrate the distinction. New Relic’s availability commitment gives eligible customers a conditional termination remedy for defined availability shortfalls, described as exclusive for those failures. Datadog’s published master subscription agreement separately caps ordinary aggregate liability at the fees paid for the affected services in the preceding 12 months and excludes losses including lost profits and business interruption. The latter provisions have stated exceptions, including gross negligence, wilful misconduct or fraud and the agreement’s indemnification obligations. ^{12, 13}

These examples do not identify either company as the supplier involved in Polymarket’s incident or establish Polymarket’s contractual position. They show why a service-level promise cannot be treated as a commitment to reimburse an operator’s entire incident bill.

Before signing, buyers should compare the potential loss with what the actual contract permits them to recover: customer reimbursements, response costs, interruption losses and losses caused by an emergency shutdown. Which are excluded, which sit within a fee-based cap, and does any indemnity cover the relevant claim? A separate security cap or insurance policy also needs its scope checked. Any uncovered amount remains an exposure for management to assess. A right to terminate is useful only if the supplier can also be disconnected safely.

Four decisions that should have an owner

An operator can turn the analysis into four concrete tests of its supplier arrangements:

This is iGaming Review’s proposed governance framework, not a regulator’s prescribed checklist. Its value lies in connecting decisions that can otherwise be assessed separately.

For buyers, the strongest assurance is therefore something demonstrable: the organisation can identify the code running in a sensitive customer journey, control changes to it, remove it when necessary, and explain what happens to customers while it is absent. A component’s small size or modest purchase price does not answer any of those questions.