How to Audit Browser Privacy Settings for Data Leaks

Table of Contents

• Why Browser Privacy Settings Leak Data
  • Privacy Leaks vs. Security Vulnerabilities
• Step 1: Run a Browser Privacy Leak Test
• Step 2: Complete a Browser Permissions Audit
• Step 3: Run a Browser Fingerprinting Test
• Step 4: Perform a WebRTC IP Leak Test
  • What the test actually detects
  • Run the test in this order
  • Fix by browser
  • Interpreting the result
• Step 5: Audit Cookies, Trackers, and Extensions
  • Reviewing Extension Permissions
• Interpreting Test Results and Prioritizing Fixes
• Auditing Mobile and Private Browsing Modes
  • Why mobile is a separate audit
  • Mobile audit checklist
  • What private browsing actually does
  • Interpreting mobile and private-mode results
• Frequently Asked Questions

Last Updated: October 17, 2026

Why Browser Privacy Settings Leak Data

Your browser shares more than you think. A 2024 Georgia Institute of Technology research team built a framework called Arcanum specifically to test whether browser extensions automatically extract user data from webpages (Georgia Tech News study on browser extensions).

That is why auditing browser privacy settings for data leaks matters. Most people assume controls work because the browser says "protected." They usually do not.

At Inkwell Tools, we build privacy-respecting utilities that process core editing in your browser, so we think hard about what a browser exposes. This guide is a repeatable audit you can finish in under an hour.

Privacy Leaks vs. Security Vulnerabilities

A privacy leak is passive, unintended data sharing. A security vulnerability is a flaw an attacker can exploit.

The distinction changes how you fix each one:

• Privacy leak: your referrer header reveals the page you came from, or a tracker records your cross-site behavior
• Security vulnerability: an outdated extension lets a malicious script run in your browser
• Different fixes: privacy leaks need configuration changes; vulnerabilities need patching or removal

Most browser privacy advice conflates the two. Fixing one does not fix the other.

Step 1: Run a Browser Privacy Leak Test

Start with a baseline. A browser privacy leak test checks what your browser reveals under default settings.

PrivacyTests.org's open-source browser privacy tests examine whether a browser on default settings protects against specific kinds of data leak.

Log these three areas:

1. Tracker blocking: are third-party tracking scripts stopped by default?
2. Fingerprint resistance: does the browser randomize identifying characteristics?
3. State partitioning: are cookies and storage isolated per site?

Record the raw scores for a before-and-after comparison.

Step 2: Complete a Browser Permissions Audit

A browser permissions audit checks what sites can access: camera, microphone, location, notifications, clipboard, and file system.

Work through this checklist:

• Camera and microphone: allow only for active calling apps
• Location: set to "ask" or block entirely
• Notifications: block by default, allow per site as needed

Permissions are the easiest leak to close: either a site has access or it does not.

Step 3: Run a Browser Fingerprinting Test

Browser fingerprinting identifies a browser by collecting characteristics like screen size, fonts, time zone, and hardware details. A fingerprinting test shows how unique yours looks.

The goal is not invisibility but making your fingerprint common enough to stop being a reliable identifier.

Step 4: Perform a WebRTC IP Leak Test

A WebRTC IP leak test checks whether your real IP address escapes through WebRTC, the protocol browsers use for video calls, screen sharing, and peer-to-peer transfer.

This is the highest-priority test: an exposed IP is a direct identifier, narrowing down your city, ISP, and often your organization, exactly the detail a targeted phishing or account-takeover attempt uses to look credible.

What the test actually detects

A WebRTC leak test page opens a peer connection and asks the browser to gather ICE (Interactive Connectivity Establishment) candidates: host addresses, server-reflexive addresses (your public IP as seen by a STUN server), and relay addresses. Look for two things:

• A public IP that matches your VPN's exit address, this is a pass.
• A public IP that matches your real ISP address, this is a leak.

A local address (private range like 192.168.x.x or 10.x.x.x) is normal and not a leak by itself; it only matters if a remote site can pair it with your public address.

Run the test in this order

1. VPN off, normal window. Record the public IP the test reports. This is your baseline real address.
2. VPN on, normal window. The reported public IP should match the VPN exit. If your real address from step 1 still appears, WebRTC is leaking.
3. VPN on, private window. Repeat. Private mode does not change WebRTC behavior, but confirm it so you are not relying on a false assumption.
4. VPN on, after a browser restart. Some leaks only appear on a fresh network stack; this catches configuration that silently reverts.

Write down the IPs, not just pass/fail, you need the before-and-after record, as with the Step 1 scores.

Fix by browser

WebRTC leak behavior is browser-specific, and fixes differ:

Explore tools → →

• Firefox: set media.peerconnection.enabled to false in about:config to disable WebRTC entirely, or set media.peerconnection.ice.default_address_only to true to limit candidates to the default route. Disabling WebRTC breaks browser-based video calls, so prefer the address-only setting unless you never use them.
• Chrome and Edge: there is no built-in WebRTC kill switch. The practical controls are a VPN client that forces all traffic, including UDP, through the tunnel, or an extension that restricts WebRTC. Verify the extension's own permissions before trusting it; an extension that can read all site data is a bigger risk than the leak you are closing.
• Safari: WebRTC handling follows the system network configuration. If your VPN does not capture UDP, Safari can still expose the local interface. Test after any VPN or macOS network change.

Interpreting Test Results and Prioritizing Fixes

Not every finding needs a fix today. Rank issues by exposure and effort.

Use this order:

1. Fix now: real IP exposed via WebRTC, high-risk extension permissions
2. Fix this week: third-party cookies enabled, fingerprint fully unique
3. Monitor: minor referrer leaks, low-risk permissions

Feroot notes that continuous monitoring addresses technical challenges that manual audits cannot (Feroot on preventing website data leaks). The same logic applies to your browser: a one-time audit drifts.

For compliance requirements, keep a dated record of each audit. If regulatory requirements apply to your organization, that log is your evidence trail.

Auditing Mobile and Private Browsing Modes

Mobile browsers leak differently from desktop, and most desktop-focused guides stop there. This section covers a mobile-specific procedure and what private browsing does and does not protect.

Why mobile is a separate audit

On mobile, the browser is rarely the only collector: the OS, keyboard, the app that opened the link, and the browser's sync and telemetry all sit between you and the page. Two consequences:

• App-level tracking can bypass browser settings. A link opened inside a social or messaging app may render in that app's in-app browser, which does not honor your standalone browser's tracking protections.
• Mobile browsers expose fewer controls. Chrome on Android and Safari on iOS offer less granular privacy configuration than their desktop counterparts, so the same checklist does not transfer one-to-one.

Mobile audit checklist

Work through this on the phone itself, not from memory:

• Tracking protection: confirm the mobile browser's tracking prevention is on. Safari on iOS has Prevent Cross-Site Tracking under Settings > Safari; Chrome on Android has third-party cookie controls under Settings > Site settings > Third-party cookies.
• Private Relay or equivalent: if you use iCloud Private Relay on iOS, confirm it is on and note that it only applies to Safari and unencrypted DNS, not to other apps.
• App permissions that mirror browser access: review camera, microphone, location, and photo access for every app that can open links. An app with location access does not need the browser's permission to know where you are.

What private browsing actually does

Private or incognito mode limits local traces: it does not write history, cookies, or form data to the local profile after the window closes. That is the whole guarantee. It does not:

• hide your IP address from the sites you visit or from your network operator;
• stop fingerprinting, because your browser still reports the same screen size, fonts, and time zone;
• prevent WebRTC from revealing your address;

Run the Step 1 and Step 4 leak tests in a private window and compare. Private mode commonly scores the same as normal mode on fingerprinting and WebRTC and differs only on stored state, expected, not a bug, and proof that private mode is a local-history tool, not a privacy shield.

Interpreting mobile and private-mode results

• Private mode matches normal mode on fingerprint and WebRTC tests: expected. Do not treat it as a failure; treat it as confirmation that private mode is not doing privacy work it was never designed to do.
• In-app browser ignores your tracking settings: fix by changing the app's link-opening behavior to hand off to your hardened browser, or by not opening sensitive links from that app.
• Mobile browser offers no fingerprint randomization: this is a platform limitation, not a misconfiguration. Compensate with network-level controls and by limiting what the browser is allowed to store.

Mobile and private-mode audits are where most desktop guides stop, and where most real leaks occur. Budget the same time as the desktop pass and log results in the same dated record so the before-and-after comparison holds across devices.