The browser looks like the safest place on a computer because it looks like a window. A tab is a page. A page is an app. The operating system is somewhere underneath, doing serious things with files and processes while the browser shows us email, a spreadsheet, and a shopping cart.
That picture is old enough to be dangerous.
I do not mean that a website has become macOS or Linux. A site cannot schedule arbitrary processes, read your disk, or open a socket whenever it wants. The web has spent decades putting useful friction between a page and the machine. The point is narrower, and worse: the browser has become the layer through which we hand out much of the authority that used to sit clearly in the operating system.
It holds the sessions for the services that know us. It mediates the credentials that prove we are us. It stores durable application state. It makes network requests under a web application’s identity. It asks whether a site may use a camera, microphone, location, clipboard, or local file. It runs untrusted programs from everywhere on the internet and is expected to keep them from one another, from the machine, and from the secrets in the next tab.
That is not a document viewer with some APIs bolted on. It is critical infrastructure.
The window that became a broker
Operating systems do a few boring but consequential jobs. They execute programs, retain state, mediate access to resources, attach authority to an identity, and enforce isolation. Modern browsers do versions of all five.
They execute JavaScript and WebAssembly, schedule workers, and hand work to the GPU. They retain cookies, caches, IndexedDB databases, and files a user explicitly chooses to expose. They make HTTP requests, keep live connections, and let service workers sit between an application and the network. They carry sessions and coordinate authentication. They supervise a growing list of requests for access to physical hardware.
The interesting word there is supervise. A web application does not talk directly to your camera. It asks the browser, which decides whether the request is eligible, shows a prompt where appropriate, remembers the decision according to its rules, and exposes a constrained interface. The W3C Permissions specification calls these “powerful features” for a reason: a permission is the user’s decision to let a web application use one.
The same pattern reaches identity. WebAuthn does not hand a website the private key for a passkey. A relying party asks the browser to mediate an operation with an authenticator; the authenticator keeps the credential and scopes the result to the requesting relying party. The WebAuthn specification is explicit that script never gets the credential itself. The client platform carries the origin to the authenticator and the authenticator incorporates that origin into its response.
That is an operating-system-shaped arrangement: one principal asks for authority, a trusted layer presents the choice, and a more protected component performs the sensitive operation. The browser is now the trusted layer in the middle.
The browser capability graph is a useful way to see it:
identity
│
compute ── state ── browser ── network
│
storage / devices
│
security boundaries
The graph is not a claim that all these things have equal power. A cached image is not a USB device. It is a reminder that authority moves through the same center. A browser is where a session meets a network request, where a page meets a file picker, where an origin meets a passkey, and where untrusted code meets a renderer process.
The boundary people cannot see
This is why a browser compromise is not merely an application problem.
Start with the small version: a stolen session. Many services use the browser’s session state to recognize a signed-in user. If someone can act inside that browser context, they may not need to know the account password. They have landed beside the thing that turns a request into your request. The damage is not limited to the page that was open when it happened. The browser is a collection of identity relationships, usually spanning work, banking, source control, health, and personal communication.
Then add local authority. A page may legitimately have access to a camera during a call, to a microphone while recording, or to files the user selected for a document editor. The browser normally confines that authority to the relevant permission, origin, and interaction. That confinement matters. But it also means the browser is no longer simply representing a remote service. It is brokering access from a remote program to the local machine.
Then take the worst case: code escapes the browser’s own defenses. A browser sandbox escape is serious precisely because the browser sits beside so much authority. It can turn an exploit in a renderer, extension, or another browser component into a route toward the host operating system. Modern browsers invest heavily in making that route difficult. Chrome’s Site Isolation, for example, puts pages from different sites into separate processes and sandboxes those processes, adding a line of defense beyond the same-origin policy.
The escalation is not a prediction that every compromised tab becomes root. It is a map of why browser security is high-consequence. Sessions, permissions, processes, and host access sit on different rungs. Treating a browser as a harmless layer above the OS flattens those rungs into one comforting picture.
The real problem is composition
Security conversations often inspect one browser feature at a time. Is this permission prompt clear? Is this API origin-scoped? Is this storage partitioned? Is this process sandboxed?
Those are necessary questions. They are incomplete because authority composes.
Read access is one capability. A network request is another. Persistent storage is a third. On their own, each can have a defensible policy. Together they can create an exfiltration path that survives a reload. A credential request can be carefully scoped to an origin, but it still sits in a flow that includes the browser’s origin display, the user’s decision, an authenticator, a session, and a server-side account. A device permission can be legitimate in a video call and alarming in a page whose identity the user misread.
The useful unit of analysis is not “does this API have a permission?” It is a chain:
actor → resource → authority → boundary → composition
Who is asking? What resource do they want? Why are they allowed to use it? What stops them going further? What changes when this capability is combined with the next one?
That last question is where browser security gets difficult. The W3C’s web-platform design principles make the same point from the API-design side: if a user denies access through one API, a site should not be able to obtain what the user believes they withheld through another. The platform cannot infer a site’s real intentions from a permission prompt. The browser, the API design, and the website all share responsibility for making the requested authority legible.
This is also why “the user clicked allow” is not a satisfying security model. Consent is a moment in a larger system. The user needs to understand which site is asking, what it wants, and what lasting relationship the browser will create. The browser needs to make the boundary visible. The site needs to avoid designing a path in which the only usable choice is to hand over more authority than its task requires.
Origin is not the whole wall
The web’s most important security abstraction is the origin. It is the rule that stops one site from casually reading another site’s data. It deserves its central place. But it is not the only boundary that matters now.
There are boundaries between origins, sites, renderer processes, browser processes, extensions, operating-system accounts, and hardware devices. There are also boundaries of time: an interaction that is safe while a user is consciously editing a document can become alarming if its authority quietly persists. There are boundaries of meaning: a user may understand “allow camera for this call” while missing the distinction between a page, an embedded frame, a related domain, and an extension with broader reach.
The browser’s job is hard because it is implementing several security models at once. The origin model governs web content. Permission systems govern powerful features. Process isolation contains compromised renderers. Sandboxes reduce the damage of a process that has already gone wrong. The operating system supplies another boundary underneath. Identity systems add their own rules about sessions, credentials, and account recovery.
When those boundaries line up, the browser is remarkably good at letting untrusted code do useful things safely. When they do not, the gap is where a user gets hurt. The gap might be a confused identity, an over-broad extension, a malicious dependency, a session that has more power than its owner realizes, or a vulnerability that crosses an isolation boundary.
Treat it like infrastructure
The lesson is not to stop using browsers for serious work. That would be absurd. The web is powerful because the browser makes general-purpose computing available without asking everyone to install and trust a separate native client.
The lesson is to update the threat model.
If you build web products, ask what authority your page accumulates across identity, storage, network, and device access. Keep permissions narrow. Make requests legible at the moment they matter. Treat session protection as protection for the relationship, not merely a convenience token. Design the least-powerful path first.
If you work in security, follow capabilities across boundaries instead of auditing them in isolation. An origin check, a permission prompt, and a sandbox can each be correct while the composed path still gives an attacker something valuable. Look for the joins.
And if you use a browser for the way most of us now live and work, stop thinking of it as the safe surface above the real computer. It is part of the real computer. It is where much of your authority now lives.
That is why the browser deserves the same care we reserve for an operating system: prompt updates, a small extension surface, deliberate profile separation where the risk warrants it, and suspicion toward any workflow that asks one window to hold every identity and every permission at once.