Some findings look serious on the surface and turn out to be intentional by design. This is one of those. The technical discovery was real. The exploitation chain made sense on paper. But the triage response taught me something important about WebRTC infrastructure that changed how I approach this class of finding.
Here is the full story.
What I Found
A public API endpoint — no authentication required — returning a large JSON configuration object. Buried inside that response were two blocks of WebRTC TURN server credentials:
json
"webRTCOriginTurnServers": {
"credential": "j8Hkl0UYqwW4r",
"iceTransportPolicy": "relay",
"isEnabled": true,
"protocols": ["tcp", "udp"],
"server": "s-cdn-media.[redacted].com",
"username": "johndoe"
}json
"webRTCTurnServers": {
"credential": "j8Hkl0UYqwW4r",
"iceTransportPolicy": "relay",
"isEnabled": true,
"protocols": ["udp", "tcp"],
"server": "turn:b-{server}-turn.[redacted].com:2083?transport={protocol}",
"username": "johndoe"
}Username. Credential. TURN server address. Transport protocols. All returned to anyone who hit the endpoint — no login, no token, no headers required.
bash
curl https://[target]/api/front/featuresOne command. Full TURN credentials in the response.
What Is a TURN Server
Before getting into the finding — a quick primer on what TURN servers actually do and why they exist.
WebRTC is the technology that powers real-time audio and video in browsers — live streaming, video calls, peer-to-peer communication. When two clients want to connect directly, they first try a direct peer-to-peer path. This works most of the time. But when clients are behind strict firewalls or NAT — Network Address Translation — direct connections fail.
TURN servers solve this. TURN stands for Traversal Using Relays around NAT. When a direct connection cannot be established, both clients connect to the TURN server instead, and the TURN server relays media between them.
TURN credentials authenticate clients to the relay server. Without valid credentials, the TURN server refuses to relay traffic.
Why I Reported It
On the surface this looked like a clear credential exposure issue. Unauthenticated access to TURN credentials means:
Any external user can authenticate to the TURN relay servers, relay their own traffic through the infrastructure, consume platform bandwidth, and potentially anonymize malicious activity through the company's own servers.
I documented the full finding with Burp Suite screenshots, a video PoC showing the complete request and response chain, and a CVSS score of 7.5 High based on the potential infrastructure abuse impact.
The report was clean. The reproduction steps were exact. The evidence was solid.
What the Triage Team Said
The response came back the next day:
"The credentials discovered are intended to be shared and are used to communicate with TURN servers in accordance with RFC. Should you be able to abuse the credentials, please submit another report with a clean and concise PoC."
Closed as Informative.
Why They Were Right — The RFC Explains It
The key phrase was "in accordance with RFC." Specifically RFC 5766 and RFC 8489 — the standards that define how TURN servers work.
Here is the part that changes everything: TURN credentials in WebRTC applications are designed to be client-side. The browser needs them to establish media connections. This means they have to be delivered to the client — and that includes unauthenticated visitors who need to initiate a connection before logging in.
The WebRTC architecture deliberately puts these credentials in frontend-accessible responses because:
The browser needs TURN credentials before the user authenticates — for initial connection setup, pre-login video previews, and connection testing.
TURN credentials are typically short-lived and scoped — they are not permanent API keys or account passwords. They authenticate to a relay service, not to the application itself.
TURN servers have their own abuse controls — rate limiting, traffic caps, and connection restrictions that limit what an attacker can actually do with the credentials.
What looks like a credential exposure is actually the intended delivery mechanism for how WebRTC infrastructure works.
What I Should Have Tested Before Submitting
The triage team gave a clear signal in their response — "should you be able to abuse the credentials, submit another report." This is the actual test.
Before reporting TURN credential exposure, verify:
Are the credentials truly static or are they time-limited? Real credential exposure involves long-lived credentials. WebRTC TURN credentials often rotate on short intervals — minutes to hours.
Can you actually relay unauthorized traffic? Connect to the TURN server with the extracted credentials and attempt to relay traffic that would not be permitted to a normal user. If it fails, the credentials are scoped correctly.
Is the exposure beyond what the browser already receives? If every browser session gets these credentials anyway, extracting them from an API is not meaningfully different from intercepting them in any normal session.
What is the actual blast radius? TURN abuse requires sustained connections and generates costs — but most platforms have infrastructure-level controls that limit this impact.
When TURN Credential Exposure Is Actually Valid
Not every TURN credential finding is Informative. Here are the conditions that make it a real vulnerability:
Credentials are static and long-lived — the same username and password work indefinitely with no rotation, allowing persistent unauthorized relay access.
No rate limiting on the TURN server — an attacker can relay unlimited traffic, causing real bandwidth costs and service degradation.
Credentials grant more than relay access — if the same credentials authenticate to other internal services or expose additional functionality beyond basic TURN relay.
The TURN server has no abuse controls — traffic from unauthorized sources is not monitored or limited.
If you can demonstrate any of these — sustained bandwidth abuse, service degradation, or access beyond relay — that is a report worth submitting with a concrete PoC.
The Lesson
Context matters as much as discovery. Finding credentials in an API response is step one. Understanding what those credentials do, how they are designed to be used, and what an attacker can actually accomplish with them — that is the real assessment.
WebRTC TURN credentials look like secrets because they are in a credentials field. But by RFC design, they are client-side configuration that the browser needs to function. The question is never just "are credentials exposed" — it is "what can an attacker do with them that they could not do otherwise."
The triage team was not dismissing the finding. They were pointing at the actual test. If abuse is possible — prove it. That proof of concept would have changed everything.
Report Status: Closed — Informative Platform: Bug Bounty Program Vulnerability Type: Unauthenticated API Credential Exposure Authentication Required: None Method: Burp Suite interception + curl Data modified: None
Tags: Bug Bounty API Security Cybersecurity Ethical Hacking Web Security