SFU unauthenticated-join
Can someone join a call without a valid credential?
FOR SECURITY TEAMS
Prove your video stack is safe before an auditor, or your biggest customer, asks — and you don't have an answer.
Because a standard web-app pentest stops at the API and never touches your SFU, TURN relay, or signaling channel, we built CVSS-scored checks for the layer that's actually real-time: SFU authentication, relay-JWT validation, TURN open-relay abuse, ICE candidate leakage, DTLS, and SFrame end-to-end encryption. Findings in days.
Built and operated by a team that runs its own production SFU under sustained, active network interference — not a scanner built from reading the WebRTC RFC.
The gap your pentest skips
Your annual pentest report probably says you're clean. It's also probably silent on your SFU, your TURN relay, and your signaling channel: the actual real-time infrastructure your video product runs on.
That's not an oversight on your vendor's part. Most penetration-testing firms scope to the OWASP Top 10: the web app, the REST API, the auth flow. WebRTC doesn't fit that model. It's UDP-heavy, session-based, and needs protocol-specific tooling most generalist firms have never built, so it gets marked out of scope, quietly, in the SOW nobody reads closely. Renewing the same vendor next year doesn't close that gap; the scope has to change, not just the invoice date.
The gap doesn't stay invisible forever. It surfaces the day a customer's security team sends back a vendor questionnaire asking specifically about your media infrastructure, or a regulator asks how you tested a video-KYC, telehealth, or therapy session end to end. At that point, "we didn't get to it" is not the answer you want attached to a signature.
What we test
Seven CVSS-scored checks, run against your SFU, TURN relay, and signaling stack:
Relay-JWT alg:none
Does your relay token accept an unsigned or "none"-algorithm JWT?
Relay-JWT weak-secret
Is the signing secret guessable or brute-forceable?
TURN open-relay abuse
Can your TURN server be abused as a relay for traffic that has nothing to do with your product?
ICE candidate real-IP leakage
Does your signaling leak a participant's real IP address through ICE candidates, even when it shouldn't?
SFrame end-to-end encryption
If you claim E2EE, does the SFU actually stay key-agnostic, or can it see plaintext?
DTLS
Is the media transport using a current, correctly-configured DTLS handshake, or one that can be downgraded?
Why us
We operate oxpulse.chat, a real-time encrypted video and voice product built on our own SFU, running live traffic under sustained, active state-level network interference built specifically to detect and block real-time media. Voice and text on our platform hold at roughly 1 KB/s against that interference.
That's the difference between a scanner built from reading the WebRTC RFC and a probe suite built by a team that has spent years keeping a production SFU alive against conditions most vendors never see. It's also why the audit is fast: go-pentest, the engine behind these checks, runs the full protocol-aware suite in a fraction of the time a generalist firm would need just to build RTC-specific tooling from scratch. By our internal estimate, that's often five to ten times faster than the generalist approach.
OxPulse Security turns that operating experience into an audit practice.
How it works
- 1
Free staging preview (30 minutes)
We run a subset of the probe suite against your staging SFU live, on a call, and show you real findings before any contract exists.
- 2
Scoping call
We confirm environment (staging, or staging plus a read-only pass on production), authorization, and timeline.
- 3
The audit
All seven checks run under an explicit authorization gate: your written go-ahead, an allowlist restricted to the environments you named, per-target rate limiting so the scan can't overload your infrastructure, and a tamper-evident audit log of every request we make. Nothing runs against an environment you haven't explicitly listed.
- 4
Findings and remediation readout
You get the CVSS-scored report, plus a call where an engineer walks through each finding and what fixing it actually involves.
Social proof
OxPulse Security is a new audit practice. This page will carry named client results as soon as engagements complete. What you can verify today: the probe suite runs on go-pentest, the same protocol-aware scanning engine behind our own security posture; the safety model above (authorization gate, allowlist, rate limiting, audit log) is the same one we'd run against our own infrastructure; and the operational experience with real-time media under adversarial network conditions is documented in OxPulse's own public positioning.
Common questions
Will running these checks affect our live production traffic?
By default, no: the engagement is scoped to staging unless you explicitly authorize a read-only pass against production. Every check runs under an authorization gate: your written go-ahead, an allowlist limited to the environments you name, and per-target rate limiting, so nothing can overload your infrastructure even by accident.
We already run a bug bounty program. Isn't that coverage?
Bug bounty programs are reactive, and depend on researchers who happen to have WebRTC-specific skills, which is rare. They also don't produce the CVSS-scored, dated report most compliance reviews and vendor questionnaires actually ask for. The two aren't substitutes for each other.
Our current pentest vendor is fine. Why add a second one?
Because the scope, not the invoice, is what's missing. Ask your current vendor directly whether their SOW names your SFU, TURN relay, and signaling channel; for most generalist firms the honest answer is no. This audit is scoped specifically to what theirs skips, not a replacement for the rest of it.
How do we know this isn't a generic vulnerability scan with WebRTC branding?
The checks are protocol-specific: SFU authentication, relay-JWT signature validation, TURN open-relay abuse, ICE candidate leakage, DTLS handshake configuration, and SFrame end-to-end encryption. None of those run by default in a general web-app scanner. You can see exactly what each check does on the free staging preview, before you book anything.
What happens to the findings before we've fixed anything?
Findings go only to the technical contact you name, in an encrypted report — never posted publicly, never shared with another client, and never used as a named reference without your written sign-off. Raw scan output and captured evidence are deleted within 30 days of the remediation readout; we keep only the CVSS-scored report for your records. An NDA is signed before scoping if you need one on file.
Do you fix what you find, or just report it?
The engagement includes a remediation readout, and an engineer walks through each finding and what fixing it actually involves. Implementation itself is scoped separately; ask on the scoping call if you want it folded in.
What does it cost and how long does it take?
A fixed-scope audit is $8,000–$12,000, set by how many environments and RTC edges are in scope, with findings delivered within 10 business days of scope sign-off. An optional quarterly monitor, which re-runs the full suite against each release, is $1,500–$3,000 per quarter.
Start with the free 30-minute staging-SFU preview: no contract, no commitment. If the findings aren't specific enough to be useful, that's the honest signal to walk away before spending anything on the full engagement. Every check that runs against your infrastructure, in the preview or the full audit, runs under the same authorization gate: nothing scans an environment you haven't explicitly listed.
Pricing and scope
RTC Security Audit
$8,000–$12,000
One-time, delivered in days. All seven checks against your SFU/TURN/signaling stack, CVSS-scored report, expert remediation readout.
RTC Security Monitor
$1,500–$3,000 / quarter
The same suite re-run against each release, so a new deploy doesn't quietly reopen a closed finding.
Free preview
$0
30 minutes, live, on your staging SFU, before any contract.