BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
I'd like to say there are no security risks to a WebRTC implementation, but that would be unrealistic.
WebRTC has two layers of security concerns. The first layer is the Web browser implementation. We rely on browser vendors -- such as Google, Mozilla and Microsoft -- for WebRTC security.
Web browsers usually update automatically and enjoy fast security patches of vulnerabilities that are known to the vendor. Vendors apply automatic security updates because of their browsers' pervasiveness and huge customer bases, which are usually in the hundreds of millions.
From a protocol standpoint, WebRTC takes the strictest measures to guarantee security. It starts with enforcing encryption on the media, like the recent change by Google that WebRTC APIs only work from webpages that are encrypted via HTTPS. This results in pretty strong WebRTC security measures in browser implementations.
The second layer is developer WebRTC implementations on applications -- and this isn't as simple as browser implementations. Within their coding, some developers can be sloppy with regard to security. In many cases, security is second rate, with the developer's focus leaning toward functionality and user experience.
The recent debacle of the Nissan Leaf mobile app emphasizes this point. As it was discovered, the app's APIs were not authenticated and users could control other cars connected to the app.
This means that during a WebRTC implementation, you are left at the mercy of the service developers -- the same way you are with any other type of IT product or service.
Do you have a question for Tsahi Levent-Levi or any other experts? Ask your enterprise-specific questions today! (All questions are treated anonymously.)
Why organizations should enhance WebRTC security
Focus on WebRTC use cases to measure adoption
WebRTC implementations slowed by browser incompatibility