The Browser Has Become the New Operating System. The Security Model Is From 2009.

For most office workers in 2026, the browser serves as the operating system. The security model of the browser is from 2009. That gap sits as the attack surface.

Look at what actually runs in a browser on a Tuesday morning. Email. Calendar. Documents. Spreadsheets. Presentations. Customer records. Internal tools. Code repositories. Design files. Video calls. Chat. CRM. Ticketing. Payroll. The list runs through the browser. The applications that used to be native are now web apps. The data that used to live on the local disk now lives in the cloud, accessed through a tab. The browser runs as the desktop. The browser serves as the file system. The browser amounts to the place where the work happens.

The browser’s security model, however, was designed for a different era. It assumes the page serves as the unit of trust. It assumes the user can tell a safe page from an unsafe one. It assumes the network is hostile and the page is benign. None of those assumptions have been true for at least 10 years, and the attackers know it.

What runs in a browser in 2026

The browser in 2026 is doing things the engineers who wrote the original security model could not have imagined. WebAssembly runs native code, in the browser, with performance close to the local machine. Service workers run background processes that persist between page loads, can intercept network requests, and can run offline. IndexedDB stores gigabytes of structured data per origin. WebRTC establishes peer to peer connections for video and file transfer. The File System Access API lets a web application read and write files on the local disk, with permission. The WebGPU API gives a web application direct access to the graphics card. The Push API gives a web application the ability to send notifications, even when the tab is closed.

None of those capabilities existed in 2009. All of them are now standard. All of them are available to every web page the user visits. All of them are governed by a permission model that was designed for a much simpler browser.

The 2009 security model

The browser security model, in the form that is still mostly in use, was developed in the late 2000s. The same origin policy defines what a page can do. The page at example.com can read its own cookies, its own storage, its own DOM. The page at example.com cannot read the cookies or storage of evil.com. The boundary serves as the origin, which serves as the combination of scheme, host, and port. A page cannot escape its origin without an explicit cross origin resource sharing agreement.

This model assumed the origin was the trust boundary. The model assumed the user would mostly browse a small number of origins they trusted, with occasional visits to other origins that were treated as untrusted by default. The model assumed the worst case was a malicious origin stealing data from a trusted one, and the same origin policy stopped that.

The model is still mostly right. The model is also not enough. The user is not browsing a small number of origins. The user has 47 tabs open. Several of those tabs are SaaS applications that the user did not choose and cannot audit. Several of those tabs are integrations that load third party scripts, which run in the same origin as the application. Several of those tabs are persistent service workers that the user has forgotten about, still running, still able to make network requests, still able to read the storage they were originally granted access to.

Why tabs are not a security boundary

Two tabs at the same origin share storage. Two tabs at the same origin can read each other’s IndexedDB, each other’s cookies, each other’s local storage. If the application at that origin is compromised, every tab at that origin is compromised. The user, who has the same origin open in 3 tabs because they were working on three things, is three times as exposed, not three times as protected.

If the application at that origin loads a third party script, that script runs in the same origin as the application. The script can read the user’s data. The script can exfiltrate. The user did not consent to running the script. The application did. The script is part of the application’s supply chain, and the supply chain attack pattern sits as the same one that hit npm, just inside the browser instead of inside the build.

Why extensions are not a security boundary

Browser extensions have access to everything the user sees. A password manager extension can read every form. An ad blocker can read and modify every page. A productivity extension can read every email, every document, every chat. The extension model is, by design, total access to the user’s browsing.

The Chrome Web Store and Firefox Add-ons both have review processes. The review processes are not security audits. They check for obvious policy violations. They do not check for backdoors. They do not check for supply chain risks. A malicious extension with a year of clean history and a useful feature can, on any given Tuesday, push an update that adds a credential exfiltration routine. The user will get the update, the extension will run, and the user will not know until the breach is in the news.

The new attack surface: service workers, IndexedDB, WebRTC, file system access

Service workers are a particular concern. A service worker is a JavaScript file that the browser runs in the background, separate from the page, with the ability to intercept network requests, modify responses, and persist across page loads. A service worker can be installed by any origin, with no user visible prompt. Once installed, the service worker can outlive the user’s relationship with the origin. It can run code, send data, modify the user’s experience of other origins, all without the user knowing.

IndexedDB and the Cache API give a web application gigabytes of persistent storage. The storage is keyed by origin, which means the data does not leave the origin, but the data is also there permanently, until the origin deletes it or the user clears the site’s data. A user who has been using a SaaS application for 2 years has, on average, hundreds of megabytes of that application’s data in their browser, accessible to any script that can run in the application’s origin.

WebRTC, the File System Access API, and WebGPU each open their own channel between the browser and the local system. WebRTC establishes peer to peer connections that bypass the normal HTTP request flow. The File System Access API, with the user’s one time grant, lets a web application read and write files outside the sandbox. WebGPU gives a web application direct access to the graphics card, with the side effect that GPU fingerprinting becomes possible at high resolution.

The credential problem: cookies vs tokens vs sessions

Session cookies used to be the credential. The cookie was set by the server, scoped to a path or domain, sent on every request. The cookie could be HttpOnly, which prevented JavaScript from reading it. The cookie could be Secure, which restricted it to HTTPS. The cookie could be SameSite, which restricted cross site requests. The cookie was a primitive that the browser knew how to handle.

The cookie has been replaced, in most modern applications, by a bearer token in JavaScript memory. The token is held in a variable, attached to every API request, refreshed by a separate endpoint. The token is more flexible than the cookie. The token is also more dangerous. The token is visible to every script that runs in the application’s origin. The token is, by definition, a bearer credential. If an attacker can run JavaScript in the application’s origin, the attacker has the token, the session, and the user.

The credential, in other words, is now a JavaScript value, in memory, accessible to anything that runs in the page. The browser’s protections are unchanged. The credential’s exposure surface is larger than it has ever been.

What genuine browser isolation looks like

The honest answer is that genuine browser isolation, in the sense of running each tab in its own process, with its own isolated storage, with no shared scripting context, is not what the major browsers do. Chromium runs tabs in separate processes but they share origin storage. Firefox runs tabs in separate processes with a similar model. Safari stands as the same. The process model is for stability and resource management, not for security.

True isolation requires either running the browser in a virtual machine (slow, expensive, operationally heavy) or running the browser in a remote rendering service (Browser Isolation, RBI, or similar). Both work. Both are heavyweight. Both are a long way from the default. For most organisations, the practical answer is to reduce the number of origins the user visits, audit the third party scripts the critical applications load, treat extensions as software supply chain risk, and assume that the credentials in any active session are exposed if the application is compromised.

The bottom line

The browser sits as the operating system. The browser’s security model is from a different era. The gap stands as the attack surface, and the attack surface is where the next wave of breaches will live. The companies that take the gap seriously, with vendor risk reviews for browser extensions, third party script audits for critical SaaS, and a realistic threat model for session theft, will keep their data. The companies that do not will read about themselves in a future incident report, and the report will mention a malicious browser extension that nobody remembered approving.