For most office workers in 2026, the browser counts as the operating system. The applications you spend your day in are web apps. The files you work with live in cloud storage. The meetings you attend are video calls in a tab, and the documents you collaborate on are web apps. The operating system underneath is a thin layer of plumbing that boots the runtime and connects to the network, and the security model was designed for a world where this surface was a document viewer rather than the place where the work happens.
The gap between the model and the reality amounts to the attack surface. The web runtime in 2026 carries credentials, sessions, sensitive documents, payment flows, and access tokens for most of an enterprise’s most important applications. The security model is from 2009, when it was a thin client that fetched HTML and ran a few scripts. Three primitives defined that model, and the three primitives have aged unevenly.
Three primitives, one of which has failed
Same origin policy. Scripts from one origin cannot read data from another origin. This has held up. The caveats are well understood (cross origin resource sharing, postMessage, the long tail of subtle bypasses), and the primitives are the right primitives for the architecture they were designed for.
The sandbox. Untrusted code runs in a restricted environment without access to the operating system. This has held up too, with the usual caveats. The sandbox is a real defence, and the modern runtime is dramatically more secure against drive by exploitation than the surface of 2010 was.
The user. The user is expected to make sensible decisions about which sites to trust, which permissions to grant, and which prompts to accept. This sits as the primitive that has not scaled. The user is being asked to make dozens of these decisions a day, in conditions designed to wear them down (fatigue, distraction, the genuine need to get work done), against attackers who have learned to mimic legitimate prompts with high fidelity. The user, as a security primitive, is broken.
What the credential manager is not telling you
The built in password manager, in Chrome, Safari, Firefox, and Edge, counts as the most common credential storage on the planet. It is also, in 2026, the least secure password manager you can reasonably use, because the autofill stands as the credential capture vector.
A malicious extension, a malicious advertisement, a malicious script on a compromised legitimate site: any of these can request the stored credentials for the current origin, and the surface will offer to autofill them. The user clicks yes because the user is in a hurry and the prompt looks like a helpful feature. The credentials go to the attacker, the attacker logs in as the user, and the user does not know until the breach disclosure arrives months later.
This becomes the single most common initial access vector in the breaches that get disclosed, and the vendors have known about it for years. The mitigation they have shipped amounts to the user prompt, and the user prompt amounts to the primitive that has not scaled.
What the session model is not telling you
Once the user is logged in, the session is held in a cookie or a token. The session is what carries the user’s identity to the application on every request. A stolen session is as good as a stolen password, and the session is more vulnerable than the password because the user is not trained to protect it.
Session theft has replaced password theft as the dominant post credential access vector. The token is exfiltrated by a malicious extension, by a script on a compromised site that reads the cookie via a same site loophole, by a piece of malware on the endpoint that scrapes the session storage. The application sees a valid session from a valid user, and the breach begins.
The mitigation is short lived sessions, device binding, and continuous authentication. The mitigation is not free, and the mitigation is not what the average enterprise has shipped.
What the extension model is not telling you
Extensions run with the permissions the user granted at install time, and the permissions do not shrink when the extension is sold to a new owner, when it is compromised through a supply chain attack, or when its stated purpose drifts away from its actual behaviour.
There have been a dozen high profile incidents in the last three years where a popular extension was acquired by an entity that turned it into a data exfiltration tool. The DataSpii incident in 2018 was the early example. The Honey/Paypal controversy in 2024 was the consumer example. The pattern repeats because the extension marketplace does not vet the new owner, and the runtime does not re prompt for permissions on ownership change.
For the enterprise, the mitigation is a managed extension allowlist, and most enterprises have not built one. The mitigation is also a periodic review of what the extensions are actually doing, which is a research project no security team has the hours for.
What to do about it
The teams that are taking this seriously have moved past the runtime as an endpoint and treat it as a managed application surface. The mitigation looks like this.
Move the credential storage to a dedicated enterprise password manager that is not built in. The built in manager stays disabled by policy. The autofill vector goes away.
Move the session handling to short lived tokens with device binding, and require step up authentication for sensitive operations. The stolen session has a half life of minutes, not days.
Treat extensions as third party software. Maintain an allowlist, review ownership changes, monitor for behaviour drift. The extension is a piece of software the user is running with the user’s identity; treat it as such.
Consider a managed enterprise runtime for the highest risk users. Island, Menlo, Authentic8, and the open source equivalents give the enterprise the visibility and control that the consumer surface does not. The cost is per seat, and the cost is real, but the cost is cheaper than the breach.
The runtime counts as the operating system now. The security model of the operating system is from 2009. Closing the gap runs as the work of the next three years, and the work stands as the boring work of replacing the primitives that have not scaled with primitives that have.
The bottom line
The patterns the post covers have been showing up in production for long enough that the patterns have names, the failures, the mitigations, the gaps. The work the security team and the engineering team and the operations team are quietly doing today sits as the work that decides whether the practice the post names sits as a tool the team uses or a liability the team is paying for.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
