Threat Model for the Web

1. What are we building?

The Web Platform is a collection of open and royalty-free technologies that enable the Web. Users interact with websites through a user agent, such as a web browser or another agent acting on the user’s behalf.

Websites contain a series of file formats - passive content such as fonts, images, and multimedia, and active content such as HTML, JavaScript, and WebAssembly - that are transmitted from the server to the user’s device and interpreted by the web browser. Passive content is decoded and rendered; active content executes with the authority of its origin and constitutes the primary attack surface of the web. This distinction is useful, but not absolute: injected CSS can still become an attack surface, for example when selector matching and resource loads are used to infer or leak page state [xsleaks-css-injection].

Websites are therefore active execution environments. A response from a web server can include executable scripts, user interface definitions, references to third-party resources, and instructions that cause the user agent to read user input, update the interface, invoke Web APIs, store or retrieve local state, interact with the underlying platform, and communicate with remote services, this is why the web browser is a critical player in this context: it executes on the user’s device code from untrusted and network-accessed websites.

Because of this complexity, this document does not attempt to define a single, exhaustive threat model for the Web. As the Web is a layered and evolving ecosystem, a single model would either be too abstract to guide development and review work, or too detailed to remain readable and useful. This follows the practical framing in Shostack’s threat modeling work: models are abstractions used to reason about what is being built and what can go wrong, and different models can be useful at different levels of fidelity [shostack-threat-modeling]. This document therefore acts as a collection of related threat models.

1.1. High-Level Web Threat Model

The High-Level Web Threat model is the most abstract model in this document. It treats the user agent as as a single process and describes only the main elements, flows and boundaries to reason at very high-level.

1.1.1. Element dictionary

1.1.2. Trust boundaries

1.1.3. Relationship to the Web Browser Threat Model

The High-Level Threat Model deliberately keeps most browser internals out of view. This makes it useful when the review is about the Web Platform as a whole: the role of origins, the main actors, and the trust boundaries between users, web content, the network, browser-managed state, and the underlying platform.

That level stops being sufficient when the design or the review depends on where a decision is enforced, which browser component keeps state, how permission is mediated, how untrusted content is isolated, or how a Web API reaches capabilities exposed by the operating system. In those cases, the browser needs to be opened up. The Web Browser Threat Model below expands P0 for that purpose.

1.2. Web Browser Threat Model

The Web Browser Threat Model outlines recurring architectural roles in modern web browsers.

Rather than treating the browser as a single component, as in the Minimalist Web Threat Model, this abstraction captures how a modern browser distributes responsibility across multiple processes with different privileges, different access to state, and different exposure to untrusted input. It also captures how the browser enforces the web security model, including origin- and site-based isolation strategies, and how it protects itself when processing input from external web servers [threat-modeling-guide].

These two concerns are related but not identical. A content process is isolated not only because web content is untrusted, but also because the browser must preserve same-origin isolation and the separation between the browser and the OS/platform. In practice, those are distinct trust boundaries, even when an implementation uses the same process architecture to support both.

Across each web browser, the implementation details differ. Even so, a common structure emerges.

1.2.1. Privileged browser process

Modern browsers include a high-privilege control component responsible for browser UI, navigation control, process management, policy enforcement, permission mediation, and access brokering for sensitive local resources. Chromium refers to this as the Browser process. WebKit refers to the UI process. Firefox refers to the Parent process [chromium-multiprocess-architecture] [webkit2-architecture-overview] [firefox-process-model].

This component should be treated as a primary trust anchor in the local browser architecture. It is where browser-managed policy is commonly enforced and where user-visible mediation typically occurs. For threat modeling purposes, this matters because the security implications of a decision depend in part on where it is made. A check performed in a privileged browser component is not equivalent to a check performed in a sandboxed content process.

In the Web Browser Threat Model diagram, the diagram refers to this process as "Browser / UI / Parent Process".

1.2.2. Sandboxed web-content execution and rendering

Web content is executed within processes like Chromium Renderer processes, WebKit WebContent processes, and Firefox Content processes, each with distinct roles in managing untrusted input [chromium-multiprocess-architecture] [webkit2-architecture-overview] [firefox-process-model].

These types of processes are exposed to untrusted web content. For that reason, they are modeled as execution environments that are expected to parse, interpret, and compute on untrusted input. Their value lies not in assuming that compromise is impossible, but in constraining what follows if compromise occurs. This is why the separation between privileged web browser mediation and web-content execution is one of the central trust boundaries in the web browser model. Implementations may also use origin- or site-based isolation strategies so that unrelated web content cannot interfere during normal use or following a compromise, but the exact isolation unit is browser-specific [chromium-process-model-site-isolation] [webkit-site-isolation-notes] [firefox-process-model].

In the Web Browser Threat Model diagram, the diagram refers to this process as "Content / Renderer / WebContent Process".

1.2.3. Network and storage

Modern web browsers also separate, or at least mediate, networking and persistent state management. In Chromium, this role is associated with the Network Service, per-profile NetworkContext objects, and StoragePartition. In WebKit, the Networking process handles network access, disk cache, and browser-managed structured site data such as Web Storage and IndexedDB. In Firefox, networking and the persistent state are distributed differently, but there is still a distinction between the two [chromium-process-model-site-isolation] [webkit-storage-documentation] [firefox-process-model].

This layer is important because it is often where cookies, caches, partitioned state, and site-data boundaries are enforced: if a specification affects fetching, credentials, storage access, or response handling, it is likely to interact with this layer.

In the Web Browser Threat Model diagram, the diagram refers to these as, respectively, "Network / Socket / Networking Process" and "Data Store".

1.2.4. Graphics, media, and Helper

Modern web browsers also separate GPU, codec, and other helper functionality into separate processes, also because media libraries are a common attack surface. Chromium separates the GPU process and additional helper-process families. Firefox separates a GPU Process, an RDD Process, a GMP Process, a Utility Process, and a Network (Socket) Process. WebKit also separates processes for related functionality [inside-browser-part-1] [firefox-gecko-processes] [webkit2-architecture-overview].

From a threat-modeling perspective, these helper processes are important because they sit at the boundary between untrusted content and complex implementation surfaces. This is also a general implementation pattern: untrusted execution or functionality prone to crashes is separated from the privileged control path to reduce impact if faults occur.

In the Web Browser Threat Model diagram, the diagram refers to this process as "GPU / Compositor / Media helper Process".

1.2.5. Element dictionary

1.2.5.1. External entities

1.2.5.2. Threat Boundaries

1.2.5.3. Processes

1.2.5.4. Data stores

1.2.5.5. Flows

The notation follows the W3C Threat Modeling Guide: E for external entities, P for processes, F for flows, S for data stores, C for threat containers, and B for threat boundaries [threat-modeling-guide].

1.3. Assumptions and External Dependencies

The System Model depends on several external systems, services, and responsibilities that are outside direct browser control but affect the browser’s security posture:

• Operating System (OS): The browser runs with privileges granted by the OS, equivalent to user privileges. Browser security goals must manifest correctly between tabs, websites, and the OS. The OS provides a higher level of security against direct network connections than browsers.

• Network/Internet: The browser’s primary function involves requesting instructions and content from arbitrary locations on the Internet. This relies on the underlying network protocols like TCP/IP, which the browser presumably trusts. The decentralised nature of the internet means unencrypted data is likely being read by someone.

• Web Servers and their backend: These are the primary sources of content, instructions (scripts, HTML), and resources for the browser. The browser must surrender control and execute commands provided by the server. A web server can also reduce a browser’s security. Websites interact with databases, off-site storage, and corporate data centres. Data flows between the browser context and these backend systems.

• Third Parties/Other Origins: Modern web applications often include resources and scripts from other origins, which must also be executed. Websites may depend on third parties for ads, analytics, or authentication databases.

• Native Applications: Other applications installed on the user’s system can potentially access browser assets directly (e.g., via file system or memory inspection).

• Cryptography: The use of and interaction with cryptographic protocols, although not specifically an input, is a category of threats to be taken into account, particularly at this moment in history in relation to the transition to post-quantum cryptography.

• External Components/Systems: Any external dependency on components or systems can impact the browser’s security.

1.4. Entry Points and Attack Surface

Entry points are read against the flows and boundaries in the System Model. They are interfaces or mechanisms through which an adversary can interact with or supply data to the system. For a web browser, these include:

• The Browser UI: The user interface itself, where user input is provided. It includes also Trusted UI.

• Network Interfaces: Ports and protocols the browser uses to communicate over the network (e.g., Sockets, RPC, HTTP/HTTPS ports).

• Web Content (HTML, CSS, Fonts, Scripts, Media): Malicious code, scripts, or content delivered from web servers. The browser runs code from untrusted sources when presented with scripts. An adversary can convince the browser to render malicious content. Specific threats are linked to the specific file formats.

• User Input Fields: Any area where users can input data, which can be manipulated maliciously (e.g., forms, URLs).

• Browser Extensions: The browser exposes interfaces for extensions to interact with the browser and web content.

• Web APIs: Both standard web APIs and potentially new, interesting APIs the browser exposes.

• Underlying Platform: Features allowing an origin to send data to the underlying platform.

1.5. Security Properties, Assets, and Invariants

The security-relevant state, resources, and properties that need to be protected when considering the web browser threat model are diverse and critical to user security and privacy:

• User Data: General user data, sensitive data, and personally identifying information.

• User Data Privacy: The ability of users to control and protect their private information and activities from surveillance, correlation, and identification. This includes avoiding identifying or correlating within and across browsing sessions without transparency or control.

• User Credentials: Login information, usernames, and passwords.

• User Cookies and Session Information: Data stored in cookies, session IDs, and session state. These can be used to recognize users across visits.

• User Device/Computer: The user’s machine and its resources, including the confidentiality and integrity of the user’s file system.

• Local Storage: Data stored locally by the browser, including cookies, localStorage, indexedDB, cache, history, and passwords.

• User Browsing History: Information about sites visited.

• User Environment Information: Operating system configuration, browser configuration, hardware capabilities.

• User Activities and Interests: Purchasing preferences, personal characteristics, and prior activities.

• Protected Resources: Any resource the user can access that should not be accessed by an adversary.

• Private Network Resources: These are different network resources that the browser can access without the user’s explicit request.

• Credentials and Encryption Keys: The browser manages Public and secret keys for encryption and signing.

• Confidential Information on Websites: Data displayed or accessible on websites.

The following properties and invariants are used as prompts for the threat analysis:

• Mutually distrusting origins remain isolated unless the platform defines an explicit, controlled communication path.

• Web content cannot directly exercise operating-system authority except through browser-mediated capabilities.

• Browser-mediated permissions are granted through browser-controlled user mediation, policy, or configuration.

• Browser-managed state is scoped according to the relevant origin, site, profile, partition, or permission boundary.

• Security-sensitive user intent is not inferred from web-controlled UI alone where browser mediation is required.

• Network, storage, rendering, and operating-system access paths preserve the boundaries shown in the System Model.

2. What can go wrong?

2.1. Threat Analysis Method

This threat model analyzes the Web Platform by iterating over the layers, elements, flows, stores, and boundaries in the System Model. For each relevant part of the model, the analysis asks what property is expected to hold, what can violate that property, who may be affected, and what harm may result. Threat sources and high-level threat families are used as prompts, but the analysis is grounded in the model above.

2.2. Threat Sources

• Browser Extensions: Browser extensions introduce numerous security vulnerabilities despite their utility. Malicious actors exploit them for sophisticated attacks like phishing, keylogging, spying, data theft, and session hijacking. They need to be installed and configured to have the permission to access a specific origin, which increases the complexity of the attack.

• Applications/Websites: Websites can be compromised and malicious. Different attacks can be directed to compromise the user’s session on the same website (e.g., stealing cookies, or generating arbitrary requests - Cross Site Request Forgery - CSRF, UI Redressing/Clickjacking), bypass the same origin and get information from different websites (i.e. Cross-Site Leaks - XS Leaks), or compromise the Browser itself (e.g., running arbitrary code into the browser processes to obtain control of the data inside the browser or to compromise the user device). Adversaries exploit existing browser functionality.

2.3. High-level Threat Index

This is an index of salient threat families for the Web Platform threat model, not an exhaustive list.

• Tracking/Privacy Loss: Fingerprinting is a method of identification of the users without their knowledge or consent. Fingerprinting touches on both privacy and security issues, has a dual significance. On the one hand, it can be used by an adversary to uniquely identify a user (a scenario normally related to privacy) i.e., allowing parties to develop user profiles or histories across different sites, often without knowledge or consent. On the other hand, it can be used to identify the type of device (a scenario normally related to security, for example for the subsequent compromise of the device). Data exposed by specifications, especially information about the underlying platform or state that persists, can contribute to fingerprinting. Some APIs can add fingerprinting surface.

3. What are we going to do about it?

3.1. Security Features and Controls

Web browsers employ a variety of security features and protection mechanisms that help preserve the properties and invariants identified earlier:

• Sandboxing: Sandboxing is a key mechanism for confining components like the rendering engine, restricting their access to the operating system and user files. It acts as a barrier between OS privileges and subprocess privileges.

• Same Origin Policy (SOP): A fundamental security control that restricts how a document or script loaded from one origin can interact with a resource from another origin.

• Content Security Policy (CSP): A security standard to prevent XSS, clickjacking, and other code injection attacks by specifying which dynamic resources can load.

• HTTPS/SSL/TLS: Protocols for secure, encrypted communication between the browser and web servers, ensuring data integrity and confidentiality in transit. HTTP Strict Transport Security (HSTS) is related.

• Input Validation and Output Encoding: These are crucial practices for handling user-supplied data to prevent injection attacks like XSS.

• Security Headers: HTTP headers instruct browsers on handling content securely.

• Anti-Phishing and Anti-Malware: Features like Safe Browsing warn users about malicious websites.

• Mixed Content Handling: How the browser treats secure (HTTPS) pages that load insecure (HTTP) resources.

• Renderer Isolation: Architectures that place complex, error-prone components like the rendering engine in a separate, sandboxed process or protection domain from the browser kernel. The browser kernel handles sensitive OS, network, and storage interactions.

• Inter-process Communication (IPC): Secure channels for communication between isolated browser components (e.g., kernel and renderer).

• Download Manager: Component handling file downloads, potentially including security checks.

• Data Minimization and Privacy Settings: Design principles and configurations to reduce the exposure of potentially identifying information.

• Trusted UI: Ensuring sensitive user interactions occur within browser interfaces that web content cannot easily spoof or manipulate.

• Permission API: Asking for explicit user permission before activating a powerful feature.

• Transient Activation: It is a gate, a window state that indicates a user has recently pressed a button, moved a mouse, used a menu, or performed some other user interaction. Sometimes used as a mechanism for ensuring that a web API can only function if triggered by user interaction. For example, scripts cannot arbitrarily launch a popup that requires transient activation ⁠— it must be triggered from a UI element’s event handler.

4. Did we do a good enough job?

5. Acknowledgment

Several individuals contributed to the document. The editors especially thanks Anna Weine.