WebRTC Skimmer Bypasses CSP to Steal Payment Data from E-Commerce Sites

WebRTC Skimmer Is Walking Right Past Your CSP

Content Security Policy was supposed to be the firewall between your checkout page and attackers hungry for card data. Turns out, threat actors found a side door - and it has been open the whole time.

A new wave of payment skimmers is exploiting WebRTC data channels to exfiltrate sensitive payment information directly from e-commerce checkout flows. The attack is surgical, stealthy, and specifically engineered to sidestep Content-Security-Policy headers that most developers trust to block unauthorized data transmission.

How the Attack Works

Traditional Magecart-style skimmers inject malicious JavaScript that phones home to an attacker-controlled domain. CSP blocks this by whitelisting approved external destinations. WebRTC flips the script entirely:

• Attackers inject a small JavaScript payload into a vulnerable third-party dependency or CDN resource already trusted by your CSP
• The payload initializes a RTCPeerConnection object - a native browser API built for peer-to-peer communication
• Payment form data is captured on keystrokes or form submission and tunneled through a WebRTC data channel
• Because WebRTC operates on STUN/TURN protocols and not standard HTTP, most connect-src CSP directives do not block it
• Card numbers, CVVs, billing addresses - all of it leaks before the transaction even completes

The skimmer leaves minimal forensic traces because it piggybacks on legitimate browser functionality rather than spawning suspicious network requests visible in standard monitoring tools.

Why Developers Keep Missing This

• WebRTC traffic does not appear in most browser devtools network panels by default
• connect-src in CSP does not govern WebRTC peer connections
• Third-party scripts from analytics, chat widgets, and A/B testing tools are common injection vectors
• Many teams audit their own code but never inventory what their trusted third-party scripts are actually doing at runtime

How to Defend Your Checkout Pages

• Audit every third-party script loaded on payment pages - treat them as untrusted by default
• Use Subresource Integrity (SRI) hashes on all external scripts: <script integrity="sha384-..." crossorigin="anonymous">
• Implement runtime application self-protection (RASP) or browser-level monitoring that flags unexpected RTCPeerConnection instantiation
• Consider isolating payment flows in sandboxed iframes with strict allow attributes that block WebRTC APIs
• Regularly run dynamic scans against checkout flows to catch injected payloads before customers do
• Monitor STUN/TURN traffic at the network edge if your infrastructure allows it

CSP is a solid layer of defense - but it was never designed to handle WebRTC exfiltration. Attackers know this. Your security posture needs to catch up.

Is your app vulnerable to similar attacks? Run an automated scan in 3 minutes with VibeShield.