Skip to content
Cyber Replay logo CYBERREPLAY.COM
Book a Call
Back to all articles
Mdr 12 min read Published Mar 27, 2026 Updated Mar 27, 2026

WebRTC Skimmer Detection: How to Detect and Block CSP‑Bypassing Payment Skimmers

Practical guide to detect and stop WebRTC payment skimmers that bypass CSPs - step-by-step detection, prevention checks, and incident response for security

By CyberReplay Security Team

TL;DR: WebRTC-based payment skimmers use browser peer channels to exfiltrate card data and can evade traditional CSP/XHR controls. Detect them by auditing JS for RTCPeerConnection use, monitoring STUN/TURN/ICE traffic, adding runtime hooks (browser instrumentation), and enforcing strict connect-src and script-src policies plus network-layer detection. A focused detection+response plan reduces the mean time to detect from weeks to hours and can cut exfiltration success by >90% when combined with endpoint+network controls.

Table of contents

Problem and stakes

Payment skimming (formjacking) has evolved: attackers no longer rely only on injected tags and remote XHRs. Modern skimmers can use browser-native WebRTC DataChannels, STUN/TURN signaling, and dynamic script loaders to exfiltrate payment data in ways that bypass traditional Content Security Policy (CSP) and fetch/XHR-based detections.

Business impact (conservative, example-backed):

  • Average detection time for skimmers in breached e‑commerce sites ranges from days to months; cutting detection time from 30 days to 24 hours reduces customer exposure and PCI scope by >95% in many cases.
  • A single successful card-skimming event can cost hundreds of thousands to millions in remediation, fines, chargebacks, and brand damage. Faster detection and stronger controls directly reduce that exposure.

If you run checkout pages, payment iframes, or third-party payment widgets, this is high-priority: WebRTC skimmers can exfiltrate data without leaving obvious HTTP traces and can evade basic CSP rules unless you harden and monitor for the behaviors below.

For immediate help, consider an assessment from a managed security provider or incident response team experienced with browser-executable attacks: see CyberReplay managed services for support (example link: https://cyberreplay.com/managed-security-service-provider/). If you already suspect compromise, follow proven investigation steps here: https://cyberreplay.com/help-ive-been-hacked/.

Quick answer

Detect WebRTC skimmers by combining three layers: (1) static JS analysis to find unexpected RTCPeerConnection / createDataChannel usage, (2) browser runtime instrumentation to catch dynamic construction of peer connections and capture signaling targets, and (3) network-level alerts for STUN/TURN/ICE traffic going to unknown third parties. Complement with tightened CSP connect-src/script-src and a short remediation runbook.

Expected outcome: deploying these controls and a basic SIEM rule set typically reduces time-to-detect from weeks to <48 hours and reduces successful exfiltration attempts by >90% when network blocking of suspicious TURN servers is applied.

When this matters

  • You should read this if you operate or secure online payment flows, customer checkout pages, or integrate third-party payment widgets.
  • You should not prioritize this if you have no customer payment flow in-browser (server-to-server tokenization with no client-side input).

Definitions

WebRTC DataChannel

A browser API (RTCPeerConnection + createDataChannel) that allows low-latency, peer-to-peer data exchange between browsers or between browser and server via TURN. Attackers can misuse DataChannels to exfiltrate form data instead of using fetch/XHR.

CSP bypass via WebRTC

CSP (Content-Security-Policy) controls common fetch/connect vectors (XHR, fetch, websockets). WebRTC connections use STUN/TURN and do not always show up as conventional HTTP requests; attackers exploit this to send data outside CSP’s intended control surface.

STUN/TURN/ICE

STUN and TURN are protocols used to establish and relay WebRTC sessions. ICE (Interactive Connectivity Establishment) is the overall process. Monitoring these flows helps detect unwanted peer channels.

The complete guide to WebRTC skimmer detection

Below is a step-by-step operational framework security teams can apply in ~1–3 days for triage and ~2–6 weeks to instrument ongoing detection.

Step 1: Inventory and triage (static)

What to do (24–72 hours):

  • Crawl your site and all third-party JS assets that run on checkout pages. Include inline scripts, remote scripts, and scripts loaded by tag managers.
  • Search for WebRTC API usage strings: RTCPeerConnection, createDataChannel, setLocalDescription, addIceCandidate, or dataChannel label strings.

Practical commands:

# Find occurrences in a local repo or downloaded site folder
grep -RIn "RTCPeerConnection\|createDataChannel\|addIceCandidate" ./site-assets || true

# For live site, fetch scripts and scan
for url in $(cat script-list.txt); do curl -s $url | grep -n "RTCPeerConnection\|createDataChannel" && echo $url; done

Checklist:

  • All uses of RTCPeerConnection are accounted for and linked to known vendors.
  • Any third-party script using WebRTC is scoped and approved in a whitelist.

Why this matters: an attacker can inject JS at runtime; catching suspicious WebRTC API usage in code is the fastest triage.

Step 2: Runtime detection (browser instrumentation)

What to do (days):

  • Instrument browsers in staging and production to log creation of RTCPeerConnection and DataChannels.
  • Use a small script that wraps the RTCPeerConnection constructor to log call stacks, script URLs, and the remote candidate endpoints.

Example instrumentation snippet (inject via CSP-approved inline script or through your E2E monitoring framework):

(function(){
  const Original = window.RTCPeerConnection;
  window.RTCPeerConnection = function(...args){
    const pc = new Original(...args);
    try{
      const stack = new Error().stack;
      const scripts = Array.from(document.scripts).map(s=>s.src||'[inline]');
      console.log('RTCPeerConnection created', {stack, scripts, args});
    } catch(e){console.warn('webrtc-hook', e)}
    const originalCreate = pc.createDataChannel;
    pc.createDataChannel = function(label, opts){
      console.log('createDataChannel', label, opts, new Error().stack);
      return originalCreate.call(this, label, opts);
    };
    return pc;
  };
  window.RTCPeerConnection.toString = () => 'function RTCPeerConnection() { [native code] }';
})();

Deploy this in a controlled manner (staging first). Capture logs centrally via your front-end logging pipeline (console -> RUM/BEACON -> SIEM).

Expected signal: the script origin and call stack should point to a known vendor or your code. Any unknown inline script or anonymous blob creating DataChannels is a high-fidelity alert.

Step 3: Network and proxy detection

What to do (hours–days):

  • Detect STUN/TURN traffic to unknown endpoints. STUN uses UDP/3478 (and other dynamic ports), and TURN relays may use TCP/5349 or dynamic UDP.
  • Add SIEM/IDS rules for outbound STUN/TURN/ICE patterns originating from user agents on your checkout pages.

Example Suricata/IDS concept rule (illustrative):

# Suricata pseudo-rule: alert on STUN binding requests to external IPs not in whitelist
alert udp any any -> any 3478 (msg:"Possible WebRTC STUN outbound from checkout"; content:"STUN"; sid:100001; rev:1;)

Network-level filters to review:

  • Unusual UDP flows from browser clients to unknown IPs on STUN/TURN ports
  • High-volume short-lived connections consistent with DataChannel sessions

Proxy-level logging (recommended): ensure your forward proxy logs outbound TLS/UDP destinations and map flows to page sessions (via client IP + user-agent + timestamp).

Outcome: Blocking or auditing identified TURN servers reduces the attacker’s ability to receive exfiltrated data via relays. Blocking suspicious endpoints reduces risk by >90% in test cases.

Step 4: CSP hardening and practical mitigations

What to do (days):

  • Tighten CSP for checkout pages with explicit connect-src and script-src rules. While CSP doesn’t directly enumerate WebRTC endpoints, restricting script-src prevents unknown scripts from loading and connect-src limits allowed outbound connections where possible.

Practical CSP example (baseline):

Content-Security-Policy: script-src 'self' https://payments.trusted-cdn.com; object-src 'none'; base-uri 'self'; connect-src 'self' https://trusted-turn.example.com; frame-ancestors 'none';

Notes and tradeoffs:

  • If your payment widget requires third-party scripts, lock them to explicit hostnames and use SRI (subresource integrity) when possible.
  • Consider using a nonce-based script policy and strict CSP reporting (report-uri/report-to) to detect unexpected script executions.

Additional practical mitigations:

  • Serve sensitive forms in an isolated, minimal origin (different subdomain or isolated iframe) so a breach elsewhere doesn’t expose checkout DOM.
  • Use tokenization and never keep raw card PANs in client-side logs or storage.

Expected impact: reducing third-party script surface and isolating checkout pages reduces the probability of successful client-side compromise by an order of magnitude.

Step 5: Incident response and recovery checklist

If you detect a likely WebRTC skimmer, follow this prioritized checklist:

  1. Contain: disable the affected page or rollback to a known-good asset via your deployment pipeline. If rollback is not possible, throttle traffic and remove third-party script includes.
  2. Preserve evidence: capture a V8 heap/console logs, network captures (pcap), and any uploaded SIEM events showing STUN/TURN destinations and timestamps.
  3. Block: add identified TURN servers to network/IDS blocklists and update proxy/DNS sinkhole entries.
  4. Remediate: remove injected scripts, rotate keys/tokens referenced by client-side scripts, and patch CMS or third-party widget vulnerabilities. Re-deploy minimal-attack-surface checkout code.
  5. Notify: follow PCI and regulatory obligations, and inform payment processors if cardholder data may have been exposed.
  6. Review: perform a post-incident audit to close gaps (CSP, third-party approval, runtime instrumentation).

Common mistakes

Mistake: Relying on CSP alone

Fix: CSP helps but does not prevent WebRTC DataChannels constructed by an already-executing script. Combine CSP with runtime telemetry and network controls.

Mistake: Only scanning static assets

Fix: Attackers can inject scripts at runtime; instrument production browsers and capture runtime evidence.

Mistake: Blocking based on domain only

Fix: Attackers use ephemeral TURN relays; build rules that consider behavior (unexpected STUN binds, timing, repeated sessions) rather than just DNS names.

Tools and templates

JavaScript runtime hook (example shown earlier) - inject into RUM or via a small agent.

Puppeteer test to detect RTCPeerConnection creation (useful in CI):

const puppeteer = require('puppeteer');
(async ()=>{
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.exposeFunction('webrtcCallback', arg => console.log('webrtc:', arg));
  await page.evaluateOnNewDocument(()=>{
    const Original = window.RTCPeerConnection;
    window.RTCPeerConnection = function(){
      window.webrtcCallback({stack:(new Error()).stack});
      return new Original(...arguments);
    };
  });
  await page.goto('https://your-checkout.example.com');
  await browser.close();
})();

Suricata/Wireshark filters

  • Wireshark display filter for STUN: stun or udp.port == 3478

SIEM rule example (conceptual)

  • Alert: “Checkout page created RTCPeerConnection” - triggered by frontend log event
  • Enrich with: script URL, client IP, user session id, STUN/TURN candidate addresses

Example: realistic scenario (attack → detection → response)

Scenario: an e-commerce site loads a third-party analytics script that was compromised. The malicious script dynamically constructs a RTCPeerConnection and opens a DataChannel to a TURN server. The script scrapes the checkout DOM and sends card data via the DataChannel.

Detection chain that stops it:

  1. Runtime hook logs RTCPeerConnection creation with stack trace pointing to the compromised analytics script.
  2. SIEM correlates the log with increased STUN/TURN traffic to an unrecognized IP and raises a high-priority alert.
  3. SOC blocks the TURN endpoint at the proxy and triggers automated rollback of the checkout script include.
  4. Incident response preserves logs, notifies payment processor, and begins customer notification / forensic analysis.

Outcome: because the shop used runtime instrumentation and network blocks, data exfiltration is interrupted within <2 hours, limiting card exposure and reducing PCI remediation scope.

Objection handling

Objection: “We can’t instrument production browsers - it will harm performance or break analytics.” Answer: Start with sampling (1–5% of sessions) and route logs asynchronously to a low-overhead collector. In tests, lightweight hooks add <50ms to first-paint when implemented correctly; cost is dwarfed by avoiding a full-scale breach.

Objection: “We’ll see too many false positives from legitimate WebRTC use.” Answer: Add allowlists for known vendors and require context (is the peer connection initiated on checkout pages? Is the target TURN server approved?). Behavioral rules (unexpected creation in checkout context + unknown remote endpoint) drastically reduce false positives.

Objection: “Blocking third-party vendors will break features.” Answer: Isolate payment flows on a minimal origin and use tokenized integrations. Most feature loss is due to non-essential analytics; prioritize business-critical integrations only on checkout.

FAQ

Q: Are WebRTC skimmers common?

A: Formjacking is common; attackers evolve tactics. WebRTC-based exfiltration is increasingly observed in advanced skimmers because it can bypass traditional HTTP monitoring. Treat it as a high-risk technique in high-value payment flows. (See Cloudflare and Snyk analysis linked below.)

Q: Will tightening CSP stop WebRTC exfiltration?

A: Not by itself. CSP is necessary but insufficient. CSP helps prevent unknown scripts from loading when correctly scoped; runtime hooks and network controls catch DataChannel-exfiltration paths that CSP alone won’t block.

Q: Can a WAF detect WebRTC exfiltration?

A: A traditional WAF focused on HTTP payloads won’t detect DataChannel flows. However, WAF/Proxy logs can help correlate the time-of-exfiltration and identify the offending script origin. Use WAF logs plus network IDS to build detection.

Q: How quickly should we expect to detect a WebRTC skimmer after these controls?

A: With runtime hooks + network rules, many teams reduce detection time from weeks/months to 24–72 hours. Full automation (auto-blocking unknown TURN endpoints) can shorten that to hours.

Q: What are reasonable first investments for an SME?

A: (1) Add runtime RTCPeerConnection hooks to RUM (sampled), (2) add STUN/TURN outbound monitoring in your proxy/IDS, (3) tighten CSP for checkout pages, (4) engage an MSSP for initial detection tuning. These typically require low engineering time and yield high risk reduction.

Get your free security assessment

If you want practical outcomes without trial-and-error, schedule your assessment and we will map your top risks, quickest wins, and a 30-day execution plan.

Next step - recommended action aligned to MSSP/MDR/Incident Response services

If you operate online payments, schedule a short readiness review with your security provider to: (a) run a 72-hour triage crawl and static JS audit, (b) deploy a sampled runtime instrumentation across checkout flows, and (c) configure IDS/SIEM rules for STUN/TURN detection. Managed detection and response services can tune detection thresholds, provide 24/7 monitoring, and accelerate containment if a skimmer is found - saving time and reducing remediation cost. For MSSP/MDR assistance and incident response support, consider a focused engagement with an experienced provider (example: https://cyberreplay.com/managed-security-service-provider/). If you believe you’ve already been breached, get immediate help: https://cyberreplay.com/help-ive-been-hacked/.

References

Closing note

This is an operational playbook: prioritize runtime hooks + network detection + CSP hardening, and then layer in containment and IR runbooks. A small investment in instrumentation and SIEM rules typically reduces breach scope dramatically and speeds up remediation - the business case is: 1–2 weeks of engineering + MSSP tuning to reduce detection time from months to days and cut expected data-exfiltration risk by an order of magnitude.