Browser Security: How Your Browser Is Attacked, Tracked and Hardened

Your browser is attacked through bugs in the browser itself, through extensions you install and through sites that abuse features like WebRTC and canvas to identify you. It is hardened by keeping it updated, restricting third-party cookies and extension permissions, turning on HTTPS-Only mode and encrypted DNS, and then testing the result rather than assuming it worked.

The security model: two promises the browser makes

Everything a browser does to keep you safe rests on two mechanisms, and it is worth understanding them before touching a single setting, because most settings only adjust how strictly these two are applied.

The first is the same-origin policy. An origin is the combination of scheme, host and port: https://bank.example is a different origin from https://ads.example and from http://bank.example. Script running in one origin cannot read the documents, cookies or storage of another. This is the rule that stops a tab with a news site from reading the balance in your banking tab.

The second is the sandbox. Each site, or group of sites, renders in its own operating-system process with almost no privileges: it cannot open files, cannot talk to other processes, cannot see the rest of your system. If a page exploits a bug in the rendering engine, the attacker lands inside that empty box and needs a second bug, a sandbox escape, to get anywhere useful. Chromium's site isolation and Firefox's Fission project both exist to make the boxes smaller, so that even a renderer compromise cannot read another site's data.

A browser scan checks whether those promises are actually being kept in your copy. The Browser Security & Privacy Check loads test resources that carry security headers and observes whether the browser obeys them: whether it refuses to frame a page that sends X-Frame-Options: DENY, whether it blocks a script forbidden by a Content-Security-Policy, whether it honours nosniff. A browser that fails those tests is either very old, running with a policy override, or has an extension interfering. That is the approach BrowserAudit pioneered and it is more informative than any version string, because it measures behaviour.

Why the version number comes first

Browser vendors ship a new stable release roughly every four weeks, and most of those releases fix vulnerabilities that a page could exploit just by being visited. Some are found internally; some are found because they were already being used against real people, which is what a zero-day means: a bug the attacker knew about before the vendor had a fix. Once the fix ships, the bug is public, the patch can be reverse-engineered, and every browser that has not updated is now running a known-exploitable hole. The window between the patch existing and your browser applying it is the patch gap, and it is the single most important number in browser security.

The guide to browser updates explains why the gap is often longer than people assume. Auto-update on Chrome and Edge downloads the new version in the background but does not apply it until you restart, so a browser left open for three weeks is three weeks behind. Firefox behaves similarly. The outdated browser check compares your reported version against the current stable release and is the first thing to fix if it fails: nothing else on this page matters if the sandbox has a known escape.

How a browser leaks who you are

Being attacked is the dramatic risk. Being identified is the everyday one. A browser gives away identity through several channels, and each has a different fix.

Fingerprinting: identification without cookies

A fingerprint is built from facts your browser reports to any page that asks: user-agent string, screen size, time zone, installed fonts, language list, the exact way your GPU renders a canvas drawing or a WebGL scene, the audio stack's floating-point output. Individually each is mundane. Combined, they often identify one browser among millions, and the identifier survives clearing cookies and opening a private window, because it is derived from what the browser is rather than what it stores.

The EFF's Cover Your Tracks project measures this as bits of identifying information: a signal that splits the population in half contributes one bit, and about 33 bits are enough to pick out one person on Earth. The fingerprint uniqueness check applies the same idea, and two of its components get their own findings: canvas and WebGL exposure, which are the highest-entropy signals on most machines. The fingerprinting guide goes through each signal, and its conclusion is unfashionable but correct: the way to reduce fingerprinting is to look like more people, not fewer. Firefox's resist-fingerprinting mode and Tor Browser standardise values across users; a hand-tuned browser with fifteen privacy extensions is more unique, not less.

WebRTC: the feature that tells sites your real address

WebRTC lets two browsers exchange audio, video and data directly, which is how in-browser video calls work. To connect directly, each browser must discover its own network addresses, including the local address behind your router and the public address assigned by your ISP, and it does that using STUN servers. The problem is that a page can start that discovery without any call in progress, and in some configurations the addresses it gathers are the ones a VPN was supposed to hide, because the request goes out through the physical interface rather than the tunnel.

The WebRTC leak guide explains the mechanism and the per-browser fixes: Firefox exposes media.peerconnection.enabled in about:config; Chromium browsers need either a VPN client that installs a WebRTC policy or an extension that sets it; Safari restricts local-address exposure by default. The WebRTC & IP Leak Test is the definitive check: it shows the address your connection presents alongside every address WebRTC can enumerate from inside the page, and if a VPN is on and those differ, the VPN is not doing what you think. The WebRTC IP leak check in the full browser scan runs the same comparison.

Cookies: first-party useful, third-party tracking

A cookie is a small value a site asks the browser to store and send back with future requests. A first-party cookie belongs to the site in the address bar and is how you stay logged in. A third-party cookie belongs to some other domain whose resource the page embedded, an advertising script for instance, and because the same third party is embedded on thousands of sites, its cookie becomes a cross-site identifier.

Safari and Firefox block third-party cookies by default and have for years. Chrome announced, delayed and in 2024 abandoned a plan to phase them out, and as of 2026 still allows them unless you turn them off. The third-party cookies check tells you which state you are in. The cookies guide covers how they work, what Secure, HttpOnly and SameSite mean on the receiving end, and why browsers now default cookies without a SameSite attribute to Lax, which the SameSite default check confirms. The short version of the advice: block third-party cookies everywhere, and consider deleting first-party cookies automatically on tab close for sites you do not need to stay logged in to.

Referrers and client hints

Two smaller leaks are worth knowing. When you click a link, the browser can send the full URL of the page you came from in the Referer header; if that URL contained a session token or a search query, the destination now has it. Modern browsers default to strict-origin-when-cross-origin, which sends only the origin to other sites, and the referrer leak check confirms yours does. User-Agent Client Hints replace the old user-agent string with a set of headers a site must request explicitly; the client hints check shows what yours will hand over when asked.

What private browsing actually does

Every browser has a private or incognito mode. It does exactly one thing: when you close the window, it discards the history, cookies, cache and form data from that session, so someone using the same computer afterwards sees no trace.

It does nothing else. Websites see the same IP address, the same fingerprint and the same logins you type. Your network, whether home ISP, employer or coffee shop, sees the same DNS lookups and connections. The private browsing guide works through each assumption people make and what actually holds. The position it takes is that private mode is a local hygiene feature, and anyone using it for anonymity from a website or a network needs a VPN, Tor, or both, depending on who they are hiding from.

Connection privacy: closing the two plain-text gaps

Even with every site on HTTPS, an ordinary connection still leaks in two places. The first is the initial request: type example.com into the address bar and most browsers first try http://, giving anyone on the network a chance to intercept that plain request and redirect it somewhere else before the site upgrades you. HTTPS-Only mode reverses the default: the browser tries HTTPS first and asks before ever falling back to plain HTTP. Firefox, Chrome, Edge and Safari all offer it now under slightly different names. The HTTPS-Only mode guide explains the downgrade attack it prevents and where to find the setting in each browser.

The second gap is DNS. Before any connection, the browser asks a resolver to translate the hostname to an address, and by default that question goes out in plain text over UDP port 53, readable by the network and answerable by anyone who can inject a response. DNS over HTTPS (RFC 8484) and DNS over TLS (RFC 7858) wrap the query in encryption so that only you and the resolver you chose see it. The browsers expose DoH directly; Firefox, for example, accepts a custom resolver URL:

Settings → Privacy & Security → DNS over HTTPS
  Protection level: Max Protection
  Provider: Custom
  URL: https://dns.quad9.net/dns-query

Encrypted DNS hides the lookup, not the destination: the network still sees the IP you connect to and, unless Encrypted Client Hello is in use, the server name in the TLS handshake. The secure DNS guide is honest about that limit and about the trade-off of moving trust from your ISP to a resolver operator, and still concludes that enabling it is worth doing for anyone on a network they do not control.

Extensions: the trust boundary you keep moving

Websites live inside the sandbox. Extensions live outside it. An extension granted access to all sites can read every page you load, every form you fill and every cookie you hold, and can alter what you see. That is not a flaw; it is what an ad blocker or a password manager needs in order to work. It means the question to ask of an extension is not "is it popular" but "what has it been granted, and who controls it now". Extensions get sold, and a buyer who paid for a hundred thousand installs has a plan to recoup the money. Extensions get hijacked when a developer's account is phished, and the malicious update installs silently.

The permissions live in the manifest, and reading it is not hard. This fragment is from a typical extension that would trigger the broad host permissions finding:

{
  "manifest_version": 3,
  "name": "Coupon Finder",
  "permissions": ["tabs", "storage", "webRequest", "scripting"],
  "host_permissions": ["<all_urls>"],
  "content_scripts": [{
    "matches": ["<all_urls>"],
    "js": ["inject.js"],
    "run_at": "document_start"
  }]
}

<all_urls> in both places means a script runs on every page before the page's own code, with the ability to read and rewrite it. For a coupon extension that is far more than the job requires. The extension safety guide explains each permission in plain terms, the warning signs of a risky extension, including obfuscated code, calls to unexplained endpoints and code fetched at runtime, and a practical audit of what you already have installed. The Browser Extension Analyzer automates the reading: upload a Chrome, Edge or Firefox package and it lists every permission, host pattern, content script and external endpoint with the risk each carries. Manifest V3, which Chrome finished moving to in 2025, removed the ability to run remotely fetched code, which closes the worst class of abuse but does nothing about an extension that was malicious in its own shipped code.

Passwords in the browser

Chrome, Firefox, Safari and Edge each include a password manager, and the most consequential thing to say about them is that any manager beats reuse. A browser manager generates unique passwords, fills them only on the matching origin, which defeats most phishing pages automatically, and syncs them across devices under your account. The dedicated managers add stronger local encryption models, sharing, cross-browser support and better recovery options. The browser password manager guide compares the two on encryption at rest, what happens if the sync account is compromised, and phishing resistance, and lands on a clear recommendation: a built-in manager with a strong account password and a second factor is good; a dedicated one is better if you use more than one browser or share credentials with anyone.

The settings that actually matter

Settings pages are long, and most entries change nothing about your real exposure. The browser security settings guide narrows the list to the ones that do, per browser, with the trade-off for each. This is the summary:

Two settings the table leaves out deliberately: disabling JavaScript entirely, which breaks the modern web and makes you highly identifiable as one of the few who did it, and blanket user-agent spoofing, which tends to create contradictions between the claimed browser and the observable one that make a fingerprint more unique. The Global Privacy Control check and the JavaScript check in the scan report where you stand on both.

Testing whether it worked

Settings are intentions. A test is evidence. The "is my browser secure" checklist pairs every item above with a way to verify it, and this is the short procedure:

1. Open the About page and confirm the version matches the vendor's current stable release. If a restart is pending, do it now and start again.
2. Run the browser check. Read the policy-enforcement results first: a failure there means something is overriding the browser's own protections, usually an extension or a corporate policy.
3. If you use a VPN, connect it, then run the WebRTC test. The public address WebRTC reports must match the VPN's address, and no local network address should appear at all.
4. Look at the fingerprint uniqueness result. Do not chase a perfect score; note whether canvas and WebGL are the main contributors and decide whether resist-fingerprinting or a browser with built-in randomisation is worth the compatibility cost for you.
5. Open your extensions page. For each one, ask what it does, whether it needs access to all sites for that, and when you last used it. Remove anything that fails those questions; analyse anything you keep but cannot account for.
6. Repeat after every major browser update and every time you install an extension, because both can reset or extend what the browser allows.

A browser that passes these tests is not invulnerable; a zero-day in the rendering engine does not care about your cookie settings. But it is a browser where the known, cheap, well-understood mistakes have been removed, and that puts you well ahead of the population an attacker is choosing from.