When discussing online privacy and VPNs, the topic of WebRTC leaks and vulnerabilities frequently comes up.
While the WebRTC issue is often discussed with VPN services, this is, in fact, a vulnerability with web browsers. WebRTC leaks can affect these browsers: Chrome, Firefox, Safari, Opera, Brave, and Chromium-based browsers.
So what is WebRTC?
WebRTC stands for “Web Real-Time Communication”. This basically allows for voice, video chat, and P2P sharing within the browser (real-time communication) without adding extra browser extensions.
What is a WebRTC leak?
A WebRTC leak is when your external (public) IP address is exposed via your browser’s WebRTC functionality. This leak can de-anonymize you via WebRTC APIs, even if your VPN is working correctly.
If you have not protected yourself against WebRTC leaks in your browser, any website you visit could obtain your real (ISP-assigned) IP address through WebRTC STUN requests. This is a serious problem.
While the WebRTC feature may be useful for some users, it poses a threat to those using a VPN and seeking to maintain their online privacy without their IP address being exposed.
How to test for WebRTC leaks
Our guide on testing your VPN lists a few different WebRTC testing tools:
- ipleak.net – In addition to WebRTC leaks, this website also tests for IPv4, IPv6, and DNS leaks.
- BrowserLeaks WebRTC test
- Perfect Privacy WebRTC test
What does a WebRTC leak look like?
If you see your ISP-assigned (external) IP address, then this is a WebRTC leak. Below is an example of WebRTC leaks that I found when testing out a VPN service. You can see that my public IPv6 address (beginning with 2) is leaking in the WebRTC area, even while the VPN is connected and stable.
Note that a local IP address is blacked out on the left. These cannot be used to identify you. (An explanation of the difference between your local/internal IP and your public/external IP is here.)
The WebRTC Vulnerability
Anyone seeking to be anonymous online through privacy technology should take action against WebRTC leaks.
Daniel Roesler exposed this vulnerability in 2015 on his GitHub page, where he stated:
Firefox and Chrome have implemented WebRTC that allow requests to STUN servers be made that will return the local and public IP addresses for the user. These request results are available to javascript, so you can now obtain a users local and public IP addresses in javascript.
Additionally, these STUN requests are made outside of the normal XMLHttpRequest procedure, so they are not visible in the developer console or able to be blocked by plugins such as AdBlockPlus or Ghostery. This makes these types of requests available for online tracking if an advertiser sets up a STUN server with a wildcard domain.
Essentially, this means that any site could simply execute a few Javascript commands to obtain your real IP address through your web browser.
WebRTC leak solutions
Here are two options for dealing with the WebRTC issue:
1. Disable WebRTC in the browser (Firefox) and only use browsers with disabled WebRTC capability. (Instructions are below.)
2. Use browser add-ons or extensions if disabling WebRTC is not possible. (Disabling WebRTC is not possible with Chrome and Chromium-based browsers, such as the Brave browser.)
Note: browser add-ons and extensions may not be 100% effective. Even with add-ons, the vulnerability still exists in the browser to reveal your true IP address with the right STUN code.
WebRTC fixes for different browsers
Below are different fixes for various browsers.
Firefox browsers
Disabling WebRTC is very simple in Firefox. First, type about:config into the URL bar and hit enter. Then, agree to the warning message and click the continue button.
Then, in the search box type “media.peerconnection.enabled“. Double click the preference name to change the value to “false“.
That’s it.
WebRTC is now disabled in Firefox and you won’t have to worry about WebRTC leaks.
Chrome WebRTC (desktop)
Since WebRTC cannot be disabled in Chrome (desktop), add-ons are the only option (for those who do not want to just give up on using Chrome).
As pointed out above, it is important to remember that browser add-ons are may not be 100% effective. In other words, you may still be vulnerable to WebRTC IP address leaks under certain circumstances. Nonetheless, here are some add-ons that may be worth considering:
Note: Unlike with Firefox, these extensions only change WebRTC’s security and privacy settings.
Recommended solution: stop using Chrome.
Disable Chrome WebRTC on Android
On your Android device, open the URL chrome://flags/#disable-webrtc in Chrome.
Scroll down and find “WebRTC STUN origin header” – then disable it. For safe measure, you can also disable the WebRTC Hardware Video Encoding/Decoding options, though it may not be necessary.
Note: Android users can also install Firefox, and disable WebRTC via the steps above.
Chrome iOS WebRTC
Chrome on iOS does not appear to implement the vulnerable parts of WebRTC that could expose local or external IP addresses (yet).
Brave WebRTC leaks
Because the Brave browser is based on Chromium, it is also vulnerable to WebRTC IP address leaks, even when you are using a VPN.
There are two ways to block WebRTC in the Brave browser:
Method 1: Fingerprinting protection
Go to Settings > Shields > Fingerprinting blocking > and then select Standard or Strict. This should take care of all WebRTC issues – at least on desktop versions of Brave (Windows, Mac OS, and Linux).
Note on WebRTC handling policy
You can also adjust the WebRTC handling policy if you go to Settings, click on the search glass in the upper-right corner, and then enter WebRTC. Under the WebRTC IP Handling Policy click the drop down menu and you can see the options below.
Note: To understand the different options with WebRTC handling, Brave has an article on the topic here. Below are the different options:
I have now tested this with the latest versions of Brave for Windows and Mac OS. Based on my tests, if you already have Fingerprinting blocking set to enabled, you should not experience any WebRTC leaks.
Note: I have seen some complaints from users who claim that WebRTC is not getting blocked on iOS, even after making the changes above. Brave developers appear to have confirmed this issue and are working on a fix.
Safari WebRTC
WebRTC leaks have traditionally not been an issue with Safari browsers (on Mac OS and iOS devices). However, Apple is now incorporating WebRTC into Safari, although it’s still technically an “experimental” feature. Nonetheless, it’d be wise to disable WebRTC in Safari for privacy reasons. Here’s how:
- Click “Safari” in the menu bar
- Then click Preferences
- Click on the “Advanced” tab, then at the bottom check the box for “Show Develop menu in menu bar”
- Now, click on “Develop” in the menu bar. Under the “WebRTC” option, if “Enable Legacy WebRTC API” is checked, click on it to disable this option (no check mark).
That should effectively disable WebRTC in Safari.
Opera and other Chromium browsers WebRTC
Just like with Chrome, the only way (as of now) to address the WebRTC vulnerability in Opera and other Chromium browsers is to use an extension.
First, download the extension “WebRTC Leak Prevent” to your Opera browser.
Then in the Advanced options for the WebRTC Leak Prevent extension, select “Disable non-proxied UDP (force proxy)” and then click Apply settings.
Again, because this is an extension solution, it may not be 100% effective.
Now verify you don’t have any WebRTC leaks
Now that you have disabled or blocked WebRTC in your browser, you should test to verify that it is working. Here are our favorite tools for identifying WebRTC leaks:
Note: If you are seeing a local IP address, this is not a leak. A WebRTC leak will only be with a public IP address.
Here I’m running a test in the Firefox browser while also connected to ExpressVPN:
You can see the ExpressVPN client on the right, with the test results on the left. No leaks!
Note: ExpressVPN is currently our top VPN recommendation and they also have a discount for three months free, see our ExpressVPN coupon page for details.
Conclusion on WebRTC leaks and browser vulnerabilities
The WebRTC leak vulnerability highlights a very important concept for those seeking a higher level of online anonymity and security through various privacy tools.
The browser is usually the weak link in the chain.
The WebRTC issue also shows us that there may be other vulnerabilities that exist with your privacy setup, even if you are using a good VPN to hide your IP address and location. (The WebRTC issue was not publicly known until 2015.)
One other problem to be aware of is browser fingerprinting. This is when various settings and values within your browser and operating system can be used to create a unique fingerprint, and thereby track and identify users. Fortunately, there are effective solutions for this as well.
And lastly, there are many different secure and private browsers to consider, many of which can be customized for your own unique needs.
Stay safe!
Distressing that one cannot (currently) prevent webrt leaks on android apps for Firefox or its lighter Focus version.
ungoogled-chromium has WebRTC enabled?
The current advice for disabling WebRTC in the Brave browser on this page includes setting the WebRTC handling policy to “Default public interface only”. I believe that advice is wrong or outdated, since when I set it to option, BrowserLeaks.com WebRTC leak test can determine my real public IP address even through a VPN proxy. Interestingly, that is the only leak test I found that could detect my public IP address. I guess it is using UDP and most other leak tests do not try UDP.
When I changed the WebRTC policy to “Disable non-proxied UDP” then BrowserLeaks.com WebRTC leak test could no longer detect my public IP address. So I suggest updating this page to recommend that option.
Ok, I’ve tested this now on the latest versions of Brave with Windows and Mac OS and have updated the article with my recommendations. I found if you just leave the WebRTC handling policy on Default, then the Fingerprinting blocking settings should cover everything.
Your article is great, but I second what Joe said: With the recommendations of what you wrote (which were actually the default settings of Brave for me: WebRTC = Default & Fingerprinting blocking = Standard), WebRTC *DOES* leak.
Changing the WebRTC setting to “Disable non-proxied UDP” seems to do the trick.
Note: ipleak.net doesn’t seem to catch the leak, but surfshark tester does ( https://surfshark.com/webrtc-leak-test )
No. Surfshark is showing a false positive, claiming there is a leak when there is not one. I just tested this.
No, it does not leak. I have tested this again. Seeing an IP address in the WebRTC box does not mean there is a leak. You may see your VPN servers IP address or even a local IP address, and neither of these are WebRTC leaks. And as I noted in replying to your other comment, the Surfshark WebRTC testing tool gives you a false positive, when there is actually no leak (tested today).
Sven, thanks for testing and replying. I’m sure you have tested, and I’m sure what you say is the results you are getting… in your test environment. I am getting the results I am telling you, and I assure you that for me it does leak. As I’m pretty sure it must be the case of the previous poster and some other people.
Note: I am using a remote desktop, which has kind of the same configuration as my computer, and there, it does not leak! I am even not really able to understand why it leaks on one side and not the other. They seem fairly identical.
Anyway, SurfShark shows MY (unproxied) IP, it cannot possibly get from anywhere else. So, no, it is not a “false positive”. It is solved by changing the configuration in Brave as indicated, and in Chrome and Chromium, by downloading an extension (I used “WebRTC control” which works great: https://chrome.google.com/webstore/detail/webrtc-control/fjkmabmdepjfammlpliljpnbhleegehm ). This extension does have an internal test for the leak, which shows the same results as SurfShark (showing my very own unproxied IP).
Interestingly enough, Chrome, Chromium and Brave are all 3 leaking on my computer. On my fairly identical remote destop config, they are not, all 3 of them (not showing any IP at all, before you start believing it was showing the VPS IP).
Please, don’t be so sure and potentially put some people at risk. There are instances (I don’t know when, why nor how) where WebRTC *IS* leaking for some people with a VPN as an extension on the browser (yes, this is the setting: No VPN on all the computer, but a VPN extension on the browser.. You may argue it’s a bad idea, and fair enough, but this is what I need according to my situation and what lead me to your article thanks to a google search. It does not seem specific to an extension in particular as I’ve tested a bunch of them). Brave safe settings in this situation are NOT the one you advise. And for Chrome and Chromium, you have to install an additional extension to be able to tweak the settings as in Brave (to “Disable non-proxied UDP”)
Also, SurfShark tool is not showing a “false positive”, and beware of ipleak.net results which shows it is OK when it’s not!
Cheers.
(Note: Your website lacks an option to get a notification for new comments or at least for replies to your comment. It would be a great idea to add this)
> “leaking for some people with a VPN as an extension on the browser (yes, this is the setting: No VPN on all the computer, but a VPN extension on the browser.. You may argue it’s a bad idea, and fair enough, but this is what I need according to my situation”
Wow. So you are not even using a VPN desktop app on your computer, but rather just a browser proxy extension? Well that changes everything and my advice does not even apply to you, so of course you may be getting totally different results. I am testing everything behind a VPN client on Windows or Mac OS and not getting any WebRTC leaks with Brave.
“Well that changes everything and my advice does not even apply to you, so of course you may be getting totally different results.”
Right. This may seem obvious to you, but nothing really indicates it in the article. Especially not for people coming directly from google searching for a solution to their WebRTC leak problem. Maybe you would be surprised by the amount of people using only a browser extension VPN. Maybe an article idea for you: How it is a bad idea.
There are situations were it makes sense. For example, on VPS running on an OVZ (OpenVZ) virtualization, VPN desktop apps usually don’t run. Anyway, you now know everything (including that what may be obvious for you isn’t necessarily for the reader). Cheers.
Is there a way to block RTC exposure using LINUX instead of Windows?
We’re testdriving Linux Mint and would like security/privacy to be strong.
Please advise. Thanx.
HI,
There is nothing about “Fingeprinting” in Brave v. 1.1.22.
It is outrageous that these tech-mavens keep finding ways to SNOOP at us and risk our security without even telling us they’re doing it! Many people need anonymity, but the tech-experts deliberately foil their attempts for security and safety. It’s disgusting!
Further, some “services” (suspect many that involve google) will fail if RTC is blocked. This unwanted boundary violation problem needs to be addressed… It’s unAmerican!
There is an open source extension users of Chrome browsers can use to help mitigate Web RTC leaks called Web RTC Leak Prevent: https://chrome.google.com/webstore/detail/webrtc-leak-prevent/eiadekoaikejlgdbkbdfeijglgfdalml
Also, in the “Settings” section of UBlock Origin a user can select: “Prevent WebRTC from leaking local IP addresses”.
UBlock Origin blocking of WTC doesn’t work.
Very helpful, thank you! 🙂
I’ve tested WebRTC leak on ipleak and browserleaks and it doesn’t leak ip addresses.
But on whoer.net website it is visible. I’m using Firefox 71.
Installing add-on didn’t help.
HI, love your site and I’ve learned a lot. I use Brave. I have taken all the steps and have a vpn. I ran the test at ipleaks and everything looks good as far as leaking, except the time zone. Without vpn I’d be connected to Toronto, with vpn I’m connected to Montreal. So why would the time zone mention Toronto? Thank you for your time.
Country: Canada Canada (CA)
Region: Quebec (QC)
City: Montreal
Time Zone: America/Toronto
Latitude & Longitude: 45.4994 , -73.5703
https://chrome.google.com/webstore/detail/trace-online-tracking-pro/njkmjblmcfiobddjgebnoeldkjcplfjb
Trace can protect against:
– Canvas Fingerprinting
– Audio Fingerprinting
– WebGL Fingerprinting
– JS Crypto Currency Mining
– Common Tracking Protection (New!)
– WebRTC Leakage
– Media Device Enumeration (New!)
– User-Agent Tracking
– Browser Plugin Fingerprinting
– Hardware Fingerprinting Protection
– Beacon Requests
– Bad Top Level Domains
– Hyperlink Auditing
– HTTP Referrer Headers
– Google Header Tracking
– E-Tag Tracking
– Screen Resolution Tracking
– Battery API
– Specific Tracking Cookies
– URL Tracking Parameters
A Changelog is available here:
https://absolutedouble.co.uk/trace/information.html
Source code is available here:
https://github.com/jake-cryptic/AbsoluteDoubleTrace/
Is webrtc leak an issue If i use a browser from within a virtual machine?
Yes, it could still be an issue.
This article implies that when you’re connected to a VPN, WebRTC somehow leaks your true public IP address. This is not true. WebRTC does _NOT_ leak your true public IP. It makes your local IP (i.e. 192.168.1.136) available for establishing peer-to-peer sessions between devices on the same router (e.g. you want to view your home security camera from your couch, no reason for that traffic to go over the internet). There’s not a whole lot that someone on the internet can do with your local IP — it’s not routable.
No. WebRTC can leak your local AND public IP:
https://github.com/diafygi/webrtc-ips
In my case my VPN replaces the local IP with a local IP belonging to the VPN company if WebRTC is enabled (as seen on browserleaks.com) This is regardless if I am using Firefox or any of my Chromium based browsers.
My VPN protects this type of leak for me.
However, since I am not using any services (voice, video etc) that needs WebRTC, I have still disabled WebRTC for all my browsers.
I forgot to mention: AND my VPN also replaces my Public IP with a Public IP belonging to the VPN server that I am connected to, even if WebRTC is enabled (on any browser).
Hi Sven
I have a question.
You have mentioned that in Opera’s privacy policy they inform that user’s browser’s history is recorded and shared with third-parties.
I have noticed that all default search engines in Opera is US based search engines, all of which is obliged by the US authorities to record all search queries made through their search engines.
Could the third-parties Opera share user’s browsing history be these US based search providers?
The fact with Opera is that users can not add their own favourite search engine to the browser and set that as default. Though it is possible to add Startpage and then type s in front of your search query.
It is also possible to install Qwant, but only as an extension and you must then search inside the extension on the top right corner of your screen.
As you have pointed out, Opera is now owned by a Chinese Consortium.
Anyway I have been wondering how come Opera only have US based search engines built in to their browser.
Anyway is a Opera user uses a good VPN, and has disabled their built-in browser proxy, then Opera has nothing to share with their third-party partners regarding that user’s browsing history? Is this correct, Sven?
Have a nice weekend and thank you for your many insightful articles.
Sorry, not sure, I haven’t looked into Opera closely beyond some basic research.
Yeah it looks good!
There does not seem to be a way to avoid these invasive snoops! We’ve got a VPN running, a browser add-on that supposedly blocks WebRTC, we’ve blocked it in U-block-origin, and we’ve set the value to False in Mozilla browser, and STILL we are finding that sites can easily identify our location and IP address. WHAT do we have to DO, to ditch these infernal snoops???? :(((
Hi Bela, disabling WebRTC will do the trick.
Hi Sven, Please reread my post. 🙂
I’ve disabled WebRTC in my browser (about:config); have a WebRTC blocker ON in my browser, got a VPN running, and have blocked WebRTC in U-block-origin, but ipleak.org can still pinpoint exact location. What more can we do, to try to have a bit of privacy (other than yanking the electrical cord out of the wall and staying offline)?? We even stopped using wireless connections but still are leaking location… ?? :-\
You should not have any WebRTC leaks if you have truly disabled WebRTC. No WebRTC blocker should be necessary with Firefox, just disable it, clear all browser cookies, history, cache, and re-test. If you are seeing a local IP address, this is not a WebRTC leak.
Man I appreciate this page. I currently stay beneath the clouds this concept/idea trace data all started. IP chase over and out.
When you almighty server can not serve you and Skype don’t get it make the server your servant.
That is just what I did! Thanks to everyone whom helped keep it together while in the heap!
Thank you
Tim Harvath 2019
An easy way to check to see if the WebRTC feature is disabled/blocked properly is on Device Info: http://www.deviceinfo.me (check for WebRTC, Local IP Address, Speakers, Microphones, and Webcams).
Is there any way to disable WebRTC at the router?
No.
I was a long-time OLD Opera User -will not use new Chrome-derived version.
Moved to Vivaldi as daily driver to good results been doing so for at least two years.
The new stable version of Vivaldi, 2.3.x, does include the built-in option to prevent broadcasting IP for WebRTC. It has been there for a few versions now.
(Unique ID still a bit of concern in some use cases.)
Thanks for the good work!
Safari was omitted even though it currently enjoys about 14% market share.
I noticed the GNU Icecat browser for Android claims not to reveal internal IP’s even with WebRTC enabled. Seems to involve the “media.peerconnection.ice.no_host” and “media.peerconnection.ice.default_address_only” preferences. Does anybody know if this is effective?
Silly question, but I assume by disabling webRTC one can no longer use chat services dependent on this. Is this correct? If correct, is there any way to leave webRTC enabled and protect against leaking?
I would like to thanks you wrote this useful article, but I found a tiny mistake typo that “First, type about.config into the URL bar and hit enter. “, the correct URL is “about:config”.
Hi Jony, thanks for the feedback, fixed.
Disabling WebRTC makes my connection quality very bad. Delay jumps from 35 to 450 ms.(when using WebRTC websites)
Any suggestion on how to fix this? Thanks in advance!
I have an Amazon Fire Tablet 7 that uses Silk as a browser. I am trying to use the chatroulette.com website on my tablet, but am not sure of how to go about it. Any help you can give me is appreciated. Thanks.
Well if gambling websites are blocked in your area, you could use a VPN that offers an app for Amazon tablets, then connect to the websites you want.
Hi admin, I just installed Brave browser on my laptop, I use vypr vpn, when I checked whoer, the anonymity shows 100 percent but it still indicates that webrtc is enabled even after I diasabled it in settings. This makes me uncomfortable – privacy and anonymity wise. Is there anything else you can recommend I should do to correct this and ensure anonymity and privacy?
Hello, I’m looking into the WebRTC issue with Brave and will be updating this guide very soon with that information. But to answer your question:
Using Brave with Fingerprinting Protection set to Block All should prevent WebRTC IP leakage. Changing your WebRTC settings to “Disable Non-Proxied UDP” also accomplishes this.
You are doing a great job in making people like me with very little knowledge of technology and internet. I recently installed brave for android reading your review. But there is no option to change webrtc settings to “disable non proxied udp” . Can you explain if there is any other way to stop webrtc leakage in the latest version of brave for android ? Or do you suggest that i use firefox and configuring it completely like you have share in one of your posts?
Hi Yoman, I haven’t looked at Brave Android yet, but one good option is Firefox Focus browser, which you can also modify using the instructions above to disable WebRTC. Firefox Focus is a privacy-focused mobile version that automatically blocks trackers and erases browsing history.
Hi Sven,
Unfortunately, I checked and rechecked my settings. My Chrome mobile (Android) browser Webrtc is still showing my router’s IP address: 192.168.x.xx.
Can you see if your fix still works on your device?
Hi Frown, that 192.168… is just a local address and not your unique public IP address. A local IP address beginning in 192.168… is not uniquely identifiable.
This is exactly the opposite. Every site can know the public IP address (it is public!), but only if you have a WebRTC leak then sites can also know the local one. I can confirm that on Android it doesn’t work
Not correct. If you are using a VPN and run a WebRTC leak test and get a result of 192.168… this is a local IP address and is not uniquely identifiable – i.e. this is not a WebRTC leak. If your unique public IP address being exposed (when you are using a VPN) then you have a WebRTC leak. See additional information here.
I understand what your’re saying Sven, but if one runs the leak test from their desktop browser and has webrtc enabled either manually or through an extension, they don’t usually see their router’s ip address.
Hello Sven, are webrtc leaks only possible in webbrowsers or do they effect other software too? Im asking because i get webrtc Leaks in Brave Browser with IKEV2 (NordVPN and Perfect Privacy). But only with Brave and IKEV2, OPENVPN works fine. Under Firefox its disabled and i get no leaks. But when it Leaks under Brave it might leak under other software where i cant check for webrtc leaks, or am i wrong?
Best regards
Hi Brad, that is correct, the WebRTC leaks only affect browsers, such as Brave because it’s built on Chromium.
I’ve been combing your web site the last couple of days. I use Mac OSX and IOS exclusively. What setup would you use for those of us who are using the Apple environment?
Hey Jack, I really like VPN.ac’s Mac OS and iOS apps – see the VPN.ac review.
Hi Sven, I’m thinking about switching to only using linux for increased privacy – what would be your suggestion for vpn in that scenario?
Hi James, you can run OpenVPN on Linux terminal. There are also providers that offer Linux clients, such as Perfect Privacy (supports Ubuntu and Linux Mint) and AirVPN.
Stun servers can run on any port over TCP and UDP. It’s technically not feasible to block WebRTC via firewall rules. You can block the default port 3478 which is used by most Stun servers but any VPN that sets this firewall rules gives its users a false sense of security. All basic IP leak tests turn out fine, but you’re still vulnerable to expose your real IP on any website that uses a Stun server, which runs on a different port.