In this talk, Tsahi Levent-Levi explains that while WebRTC provides mandatory encryption for media and forces secure signaling channels, the overall security of a WebRTC‑based application depends on how developers assemble and configure the surrounding components. He highlights common weak points such as insecure signaling logic, misconfigured TURN servers, flawed SFU setups, and vulnerable client‑side JavaScript. Levent-Levi argues that any product that enables real people—whether in regulated sectors like government, healthcare, or education, or any consumer service—to communicate must proactively address these application‑level risks. To help engineers do so, he and Philip Henke created the "WebRTC Security and Privacy Essentials" course, which catalogs roughly 50 known issues and best‑practice mitigations across UI, client, signaling, media paths, and NAT traversal. The course is positioned as a practical checklist for teams shipping WebRTC to real users, urging them not to wait for a breach before taking security seriously.
Chapters
Security and privacy are the parts of WebRTC almost everyone skips. Right up until there is a breach and it's on the front page. I'm Tsahi Levent-Levi, and here's whether you actually need a WebRTC security course. Here's why most of the time engineers are going to skip The security piece of WebRTC. And it's simple. WebRTC comes by default encrypted. You can't remove that. If you're sending media, it's encrypted. If you're doing signaling for WebRTC, well, it forces you to use HTTPS in the browser or secure WebSockets. So, you know, it's obvious, it's already secure. What can go wrong? You don't need to do nothing beyond that. But, That's not exactly true. At the end of the day, WebRTC is a set of building blocks. You've got the media piece, the signaling piece, NAT traversal, different types of servers. You take all of these pieces, you cobble them up, and build your own application. So while WebRTC itself might be very secure, your security is, you know, as secure as your weakest link. So everything that you built on top of it might fail and break. It might be something in your signaling, like auto-answer when you shouldn't, okay? Or it might be the way you've configured the TURN server, or something you've done in the SFU, or whatever JavaScript piece that you've placed in the application logic itself. So things break with WebRTC, and that's because you've missed something in the application and you forgot some of the things that you need to do to maintain security and privacy. When do you need to actually look at security in WebRTC? If your application touches real people. Not only for regulated industries like governments and healthcare and education, but everything. If you have people in there and they need to communicate with each other or with bots today, you need to maintain and build the security for your application properly. And this is exactly where the security and privacy course comes in to help you out. So what exactly will you find in the security course? Well, the WebRTC Security and Privacy Essentials course was authored by me and Philip Henke. Together in the course, we go through 50 or so different known issues and best practices related to building applications with WebRTC. We don't care there about the actual bugs of security inside WebRTC. These will be solved and fixed by Google, with the browser vendors, and the media servers that you're going to use. It's the stitch, or the line that sits between what you're using in your application logic, is where we sit. And we've built it in a way that we treat the UI, the client, signaling, media paths, NAT traversal. In different aspects of the application. So you can go one by one and like, you know, checkmarks, go through that and make sure that your application is as secure as you can be. So if you're shipping WebRTC to real users, the WebRTC Security and Privacy Essentials course is at webRTCcourse.com. I'm Tsahi Levent-Levi. Don't wait for the breach to take it seriously.
