WebRTC Data Channels Enable CSP-Agnostic Payment Skimming on E-Commerce Platforms
Attackers are deploying payment skimmers that abuse WebRTC data channels to receive malicious payloads and exfiltrate stolen card data, successfully circumventing Content Security Policy controls that block traditional HTTP-based exfiltration vectors.
Affected
Sansec researchers have identified an active payment skimming campaign that exploits WebRTC data channels as a covert communication mechanism, effectively rendering Content Security Policy protections ineffective. This represents a meaningful advancement in skimmer sophistication: rather than relying on HTTP requests or image beacon exfiltration (which CSP can restrict), the malware establishes peer-to-peer data channels to receive obfuscated payloads and transmit stolen payment card information. The attack surface is particularly acute because CSP directives do not govern WebRTC traffic in the same manner as network requests.
WebRTC data channels operate at the browser API level and are designed for low-latency, peer-to-peer communication independent of HTTP infrastructure. An attacker-controlled JavaScript payload injected into a compromised e-commerce checkout page can establish a WebRTC connection to an attacker-operated signalling server, then receive encrypted or obfuscated skimming logic through the data channel. This bypasses CSP's connect-src and default-src restrictions because WebRTC connections are not subject to the same policy enforcement mechanisms as XMLHttpRequest or Fetch API calls.
The affected organisations are likely major e-commerce platforms suffering code injection via third-party dependencies, supply-chain compromises, or malicious advertisements (classic Magecart-style attacks). The use of WebRTC specifically suggests attackers are targeting environments where defenders have implemented robust CSP policies but have not restricted or monitored WebRTC connections. Any merchant processing payment data should assume standard CSP configurations provide no defence against this vector.
Defenders should implement network-level monitoring for unexpected WebRTC signalling traffic, review third-party script dependencies for recent injection indicators, enforce Subresource Integrity (SRI) on all externally hosted JavaScript, and consider implementing WebRTC disable policies or restrictions where payment processing occurs. From a policy perspective, browser vendors should consider tightening WebRTC permissions and signalling behaviour to bring them into alignment with CSP enforcement.
This attack exemplifies a broader pattern in payment skimming evolution: as organisations strengthen one defense (CSP), attackers pivot to overlooked browser capabilities. The technique is low-cost to deploy, difficult to detect without WebRTC-aware monitoring, and highly effective at scale across compromised e-commerce infrastructure.
Sources