Threat Modeling Guide

1. Introduction

The mission of W3C is to make the Web work in accordance with the principles of accessibility, internationalization, privacy, and security. Therefore, every standard must also consider security and privacy. This consideration can be made by developing and documenting a threat model for each W3C specification.

Moreover, W3C Process mandates Wide Reviews, which include horizontal reviews described in W3C Guide. Among the horizontal reviews, we also find the security review.

During the security review, a key element is verifying the presence of the Security Consideration Section and the related Threat Model, which not only satisfies the security principle but also accelerates the review process.

1.1. Terminology

It is helpful to understand some basic yet often overlooked terminology. At the beginning of the threat chain is the threat actor, sometimes called an adversary. The threat actor is the entity from which the threat arises (Swiderski & Snyder, 2004). The threat actor has specific goals and underlying motivations. Understanding these motivations is essential to model correctly. In contrast to threat actors, the term adversary is used to describe vulnerabilities and dangers to users, whether or not a specific person or entity is behind the threat. (Allan & Appelcline, 2019\) “By anthropomorphizing these threats, we can consider their motivations.” Both threat actors and adversaries identify the source of the threat being modeled.

Then there is the threat—a potential circumstance, event, or action that could have a negative impact, e.g., on the user (ISO, 2022)—which represents a sub-goal of the threat actor (Swiderski & Snyder, 2004). Attack is how the threat is realized (Swiderski & Snyder, 2004\) and is based on taking advantage of a vulnerability \- a weakness in an asset or control that can be exploited (ISO, 2022\) \- to achieve a certain impact on an asset, as the asset is something valuable (ISO, 2022\) such as the elements inside a Threat Model (Swiderski & Snyder, 2004). If the impact hurts assets such as people, it is called harm (ISO, 2019\) or, to simplify, “harm is a threat with its impact” (Shostack, 2014).

• Assets: An abstract or concrete resource that a system must protect from misuse by an adversary (Swidersky & Snyder, 2004).

• System: a collection of functionality that can span one or more components (functional areas). A system exposes certain functionality to external entities (interactors outside the system’s control) and must protect one or more assets. (Swidersky & Snyder, 2004).

• Threats: something that, if it happens, has a negative impact. In the Open Source Security Testing Methodology Manual v3 (OSSTMM) Security is considered a function of separation between what we are protecting and the threats. This separation occurs through the application of response strategies (e.g., controls or mitigations) that create a distance between the asset and the threat.

• Responses: What controls or mitigations have we put in place, and what are their limitations? And what threats do we accept?

• Attacks: An attack is a realization of a threat; a particular instance of a threat manifesting in an operational system.

1.2. Goals of This Guides

This guide should help specification developers and implementers document and understand the threats facing the World Wide Web, with the explicit goal of improving the security, privacy, and reliability of the Web.

We take a security-first approach, as without reliable security, it is impossible to know if a system is working properly. To evaluate the security of the web (and potential extensions and innovations), we use a threat model to identify what we are evaluating, the threats we have considered, and any known responses to those threats.

It is a goal of this work to update the way the W3C identifies, captures, and communicates the security risks of its technologies, especially by developing reusable, shareable, and extensible threat models for every technology specification developed by the organization.

We provide explicit guidance on performing threat modeling and writing security considerations for specifications developed by the World Wide Web Consortium.

2. What is Threat Modeling at W3C

Threat Modeling is a family of structured, repeatable processes that together allow you to make rational decisions to secure applications, software, and systems (Shostack, 2014). During Threat Modeling, potential threats, such as vulnerabilities or the absence of appropriate safeguards, are identified and enumerated, and countermeasures prioritized (OWASP). In general terms, threat modeling is a form of risk assessment that models aspects of the attack and defense sides of an entity (NIST SP 800-53 Rev. 5, NIST SP 800-154). As a practice, Threat modeling has inspired several alternative methods for evaluating threats across various system types. Three worth highlighting are the Security Development Lifecycle (SDL) from Microsoft, Shostack’s 4 Questions from Adam Shostack, and the Auditor’s Trifecta from the Open Source Security Testing Methodology Manual (OSSTMM).

Any coherent analytical framework may yield quality threats. Our approach at the W3C embraces any analytical framework that specification developers find illustrative. We provide a common strategy for performing threat modeling using any analytical framework that enables evaluating components for threats and identifying suitable responses.

At the W3C, we ask specification developers to develop a formal threat model to capture known threats and responses of their specification. This guide provides detailed examples and advice for developing an effective Threat Model, tailored specifically to Threat Modeling for specifications.

Groups are free to innovate in their approach to threat modeling, as long as three key elements exist:

1. A clear description of the system under analysis, including a visual representation(s) of the components of the system and data flows between them, and a dictionary describing each component and flow. This can be a simplified Data Flow Diagram (DFD) as described in Shostack’s approach, a UML Sequence Diagram that shows the core information flow between components, swimlanes, or any other visual representation that provides adequate context for threat analysis. The point of the description is to introduce terminology for referring to system elements when discussing threats and responses.

2. A discussion of the threats identified by specification developers. Four types of threats should be considered:

3. target threats the specification was designed to address,

4. implementation threats that implementers should consider but which are not covered by the specification,

5. external threats whose resolution is beyond the scope of the specification but that are nevertheless considered worthy of consideration by implementers and

6. dependency threats are external threats that arise from specific pre-requisites or dependencies in the system, such as reliance on CSS or HTTP in a specification that relies on those technologies but does not control them.

7. A discussion of responses to the identified threats, describing how implementers could address them. Responses may include actions or controls outside the technology described by the specification itself. For example, a specification that relies on TLS/SSL encryption to avoid network surveillance might identify the threat and acknowledge that a working TLS/SSL subsystem is an expected response for implementers; it need not directly describe how the TLS/SSL subsystem does so.

3. Why Threat Model

We threat model to make the Web better.

Threat models are a medium for technology evaluation and communication. They provide a concrete and coherent perspective on the threats related to a set of technologies. By creating, discussing, and documenting specific threat models, stakeholders can better understand the engineering trade-offs involved in deploying innovative technologies.

At the W3C, Working Groups develop threat models to capture and document threats related to a specification as it is expected to be deployed.

Threats listed in W3C threat models should include:

1. Threats in which they are explicitly addressed by specification developers.

2. Threats inherited from other elements of the ecosystem, and relevant to the specific use-cases.

3. Known real-world or systemic risks that exist for common use cases, but are recognized as out of scope for the modeled version of the specification.

4. Threats likely to impact implementations, but for which normative constraints are deemed too restrictive.

This last category of threats is especially important when specifications offer significant extensibility or optionality. While the specification itself may introduce new threats, it is possible to know at specification time that some non-normative options and choices pose security or privacy challenges that implementers should consider when implementing the specification.

This is particularly important because of the complex landscape of technologies that come together to realize the Web. W3C specifications are necessarily deployed alongside a large family of interdependent specifications maintained by other organizations, such as Ethernet, Wi-Fi, TCP/IP, HTML, ECMAScript, DNS, and SSL. Threat modeling of W3C specifications must appropriately identify threats arising from the complex interplay of independently developed technologies. We cannot “fix” threats arising from externalities, but we can identify the harms that may result from reliance on particular capabilities.

By better understanding how W3C specifications address threats of the World Wide Web as deployed, we help make the Web more secure and privacy-respecting for everyone.

4. When to Threat Model at the W3C

Threat models, as described in this guide, should be developed collaboratively by the Working Groups writing the specification, with support from the W3C team and the horizontal groups (e.g., security and privacy groups at W3C) to identify threats.

The threat model should start in parallel with the specification itself, particularly when evaluating use cases and writing introductory explainers. A good threat model describes all the possible goals an adversary may have for a given set of functionality (Swiderski & Snyder, 2004, p. 29). These goals may be identified when evaluating the system from a use-case perspective, drafting an explainer, or teasing out the trade-offs of specific design choices. Whenever a threat is implicitly involved, threat modellers should capture it. Just as a discussion of the relevant use cases can evolve as a specification moves from inspiration to recommendation, a discussion of threats should start at the beginning of the process and be updated as discussions and specification text evolve.

When you start writing an explainer and have a first draft of the threat model, please share it with the review groups. Then, threat models, by their nature, are living documents that require continuous updates, such as when functionality is modified or new functionality is added (Swiderski & Snyder, 2004, p. 26).

A completed threat model must be prepared before formal horizontal review. A threat model should serve as the foundation for the security considerations section of the Working Group’s specifications.

If the threat model is small, it can be included directly in the Security Considerations section. If it is very large, it can be published separately (e.g., as a Group Note) and included in the Security Considerations section as an external security note (Shostack, 2014).

It is a goal of this work to update the way the W3C identifies, captures, and communicates the security risks of its technologies, especially by developing reusable, shareable, and extensible risk models for every technology specification developed by the organization.

5. How to Threat Model

Highlight the threats that most influenced the specification. Based on the discussions that led to the specification, capture the most salient threats and present them in a concise, understandable, and compelling way.

For specifications, threat modeling SHOULD focus on the idealized realization of the specification, assuming everything is implemented correctly. It SHOULD be augmented, as appropriate, with significant threats arising from common implementation errors.

The point of threat modeling specifications is to help implementers understand the security trade-offs inherent in the technology, enabling them to make informed security decisions when implementing the specification.

Downstream, we anticipate that both implementers and security professionals will extend the threat models created by working groups with their own evaluations based on implementation decisions. Such implementation-specific threat models are not expected to be standardized and may be published or not. However, they provide implementers with a coherent way to evaluate the security trade-offs of their applications when integrating the specified technologies.

There are different iterative processes for doing threat modeling, but they all use the same basic approach:

1. Model the system

2. Identify & Evaluate Stakeholders

3. Identity & Evaluate Threats

4. Consider Responses

5. Publish for consideration

6. Iterate

5.1. Model the system

The first step in creating a threat model is summarized in the question, “What are we working on?”. It typically involves defining the use case scenario, then creating a model—an “abstract representation of some process” (O’Neil, 2016)—and diagrams, a graphical representation of the model (Howard & Lipner, 2006, p. 110).

Creating good diagrams is fundamental, as they are the heart of a good threat model (Osterman, 2006). Diagrams should list and describe the various elements that make up the system (Osterman, 2007). Creating a diagram is a complex process; when modeling computer systems, multiple diagrams are often used. For this reason, in the threat modeling of a computer system architecture, a high-level diagram is followed by a series of detailed diagrams that detail the various elements (Howard & Lipner, 2006, p. 112).

This concept is similar to what happens when looking at a geographical map: on the one hand it can be useful to have various levels of zoom, and on the other hand, it can be useful to have different information (e.g., satellite images, street map, topographic map) and the well-known principle “the map is not the territory” (Korzybski, 1933), also applies here (Onofri, 2024b, slide 15). Not surprisingly, another well-known aphorism, “all models are wrong, some models are useful” (Box, 1976), is also used in modeling (Fenstermacher, 2004).

Any visualization that clearly distinguishes the various elements of your system is acceptable. Modelers MUST use visual imagery that adheres to the W3C Accessibility Guidelines https://www.w3.org/TR/wcag-3.0/. Specifically, use shapes rather than colors or shading to distinguish different types of elements.

It is also RECOMMENDED that

1. diagrams enumerate all components with unique short IDs (not just names),

2. diagrams are accompanied by a prose description of the architecture describing a common use case to give context and explanation for the diagram, and

3. diagrams are accompanied by dictionaries that enumerate and describe the elements in the diagrams. This dictionary also serves as a reference in subsequent discussions of threats and responses.

We provide an example in the Appendix A1 Minimalist Threat Model for the World Wide Web.

5.2. Identify the Stakeholders

When modeling the system, it is vital to include all affected stakeholders to answer the question “Who is affected?” or, equivalently, “Who is impacted?”. Focuses on identifying and analysing the people, groups, and entities that interact with or are affected by the system modeled in the first step. This work aims to shift the paradigm from viewing the user as an asset to be protected to the “weakest link” of the security chain (Schneier, 2015, preface section). Despite this integration, the user should always be treated as a protected entity.

This step is inspired by the Harms Modeling process described in Microsoft (2020) and is useful for integrating Threat Modeling with Harms Modeling.

Identifying stakeholders is particularly useful when analysing high-level models and technologies that can have a societal impact. A thorough understanding of stakeholders ensures that the resulting systems are not only secure but also trustworthy, recognising and respecting human rights as a fundamental design principle.

This includes understanding who the stakeholders are, what they value, how they might benefit from the technology, and how they could be harmed by it. Stakeholders typically include, but are not limited to:

• Customers: direct users or adopters of the technology.

• Non-customers: individuals, groups, or organisations indirectly affected by the technology’s operation or deployment.

• Developers and operators: those who design, implement, or maintain the system.

• Regulators and policymakers: entities establishing or enforcing rules that affect the system’s design and usage.

• Society at large: communities, environments, and ecosystems influenced by the system’s broader externalities.

To guide the analysis, it is RECOMMENDED to ask the following questions for each stakeholder category:

1. Who are the end users for your technology?

2. How should they benefit from your technology?

3. How could your technology harm them?

4. Who are the non-user stakeholders?

5. How should they benefit from your technology?

6. How could your technology harm them?

Asking these questions provides a deeper understanding of what matters to stakeholders and how these values influence their relationship with the product or system. This understanding forms the basis for identifying not only technical threats but also social and cognitive harms, ensuring that threat modeling extends beyond the system’s components to include its human and societal dimensions.

• Objective: Identify the stakeholders and understand their interests, benefits, and potential harms.

• Input: Model and use cases.

• Output: Stakeholder list with roles, values, and potential impacts, that can be harms or threats.

• Who: Standards’ Developers alone or with Domain Experts (e.g., Human Rights, Privacy, or Ethics specialists).

5.3. Identify & Evaluate Threats

The second step in creating a threat model is summarized in the question, “What can go wrong?” where threats are identified and assessed (Swiderski & Snyder, 2004, p. 111). Threats can be identified in different ways, such as experimentally, by analyzing the chain of events leading up to an attack—i.e., a kill chain —or by using a list of threats (Shostack, 2014, pp. 9, 385, 388; Penney, 2023).

Threat lists, like other types of lists used in threat modeling, are particularly useful for identifying issues on a diagram. This operation can be performed: “per element” of the diagram, where the analysis starts with the first element and evaluates all threats (Osterman, 2007a); “per interaction”, where the analysis is focusing on the data flow of the diagram, focusing on the interactions between elements (FFRI, 2016, slide 4-5), “per threat”, taking one threat at a time and figuring out which element it applies (DistriNet, 2024).

• Objective: Identify the Threats, Vulnerabilities, etc…

• An inefficient but effective method is to have lists of principles or properties that need to be respected, controls that should be in place, or threats.

• We can “brute-force” them:

  • For each component or flow, identify the threats

  • For each threat, identify the component(s) affected

• We can also use Kill Chains, Incident Analysis…

• Input: Model and Threats/Controls/Principles/Questions.

• Output: List of identified threats in the Model.

• Who: Standards’ Developers alone or with Domain Experts

5.4. Consider Responses

The third step in creating a threat model is summarized in the question, “What are we going to do about it?”. It typically involves choosing how to respond to the threats (Howard & Leblanc, 2002, p. 106).

In the literature, there are several categories of responses, some specific to threat modeling and others derived from risk management (Appendix A.4), aimed at reducing or eliminating the threat or its impact (Howard & Lipner, 2006, p. 124).

For the Threat Modeling Guide, these can be summarized in four response strategies using the ERTA mnemonics: Eliminate the threat or the asset; Reduce the threat by applying mitigations or countermeasures; Transfer to another entity or element; and Accept, meaning do nothing but accept that the threat can occur.

• Objective: understand how to address the threats, e.g.:

• Eliminate: Remove the asset or the threat.

• Reduce: Make it harder, e.g., adding a control, mitigation or countermeasure.

• Transfer: To another element or component.

• Accept: that it is not possible to mitigate (or the Group doesn’t want to mitigate, for now) the threat; it is still open and needs to be monitored.

• Input: Identified Threat List

• Output: List of countermeasures for each threat and residual threats

• Who: Standards’ Developers and Threats Experts

5.5. Publish for consideration

The fourth step in creating a threat model is summarized in the question, “Did we do a good job?” but threat models, by their nature, are living documents that require continuous updates (Swiderski & Snyder, 2004, p. 26). Also, the attacks are in a continuous evolution, and “Attackers simply ignore your threat model” (Onofri, 2024b, slide 38). This step serves as a reminder to pause, publish for consideration, evaluate the completed work, and determine what still needs to be done. For example, performing formal verification, additional cryptographic checks, and so on.

• Objective: make the model visible

• Input: List of threats and countermeasures

• Output: threat model and security considerations

• Who: Standard’s Developers

5.6. Iterate

Once you have a published version of the threat model, engage stakeholders to improve it. The specificity and curation of the most relevant threats will be improved by more parties contributing constructively. Through your working group and horizontal review, invite input and feedback, and integrate that feedback into a better threat model. Bring in external perspectives from expected users of the technology, including both end users and service providers.

The best threat models evolve over time as the threat landscape and our understanding of threats change. We learn new details about potential threats, and new threats emerge constantly.

6. Curatorial Storytelling

Tell a good story. That’s the priority.

The most important factor in the success of threat models is whether or not developers actually read, understand, and apply them in their implementations. The principles of good storytelling can help.

It’s vital that developers can quickly read and understand the threats they should consider when making engineering decisions. A threat model that is too verbose risks overwhelming readers before they capture the value of the model. Huge tables of hundreds of threats are simply hard to absorb. Instead, carefully chosen and well-ordered threats lead readers through a gradual introduction to the threats they should care about most.

Modelers should focus on the most relevant threats in their work, and order them by priority to enable readers to see the big picture even if they do not have the time and inclination to read the entire document in detail. Pick the most salient threats and present them in an order that makes sense to new readers.

This principle also applies to the diagrams that ground the threat modeling. Identify just those elements that matter to your particular threat model. This requires having an intention about the general scope of the system to be considered. Your diagrams define and illustrate that scope. For example, web browser devices, like a smart phone, contain dozens of different chips. Modeling the threats of a proposed CSS standard is unlikely to benefit from highlighting the fact that any one of those chips could be compromised in some way at the factory. Developers concerned about hardware security would be better served by creating a dedicated threat model that focuses on how the hardware might be compromised.

Choose the elements that best represent the threats you care about. Ignore the rest.

Focus on threats that either have known responses, including accepting the threats because it is understood there are no clear alternatives. Abstract threats and “areas of concern” must be further distilled into actionable threats.

Readers of threat models seek a coherent presentation of the threats and responses they should consider when implementing the modeled specification. As such, threat models should not be exhaustive lists of everything that might go wrong in a system, but rather tightly curated sets of threats and responses that illustrate the specification developers’ best thinking about threats at the time the specification was written. Any reader of a threat model should walk away with a clear understanding of the real threats people and organizations might face during deployment, along with guidance on how to address them. As a storytelling exercise, threat modellers should present the most salient threats clearly and compellingly, avoiding overwhelming the reader with extraneous details.

7. How to Write the Security Considerations Section

While it is not a requirement for any given standard to be immune to all forms of threats and attacks, it is still necessary for authors to consider as many forms as possible. Part of the purpose of the Security Considerations section is to explain what attacks are out of scope and what countermeasures can be applied to defend against them.

Once you have an early version of the Threat Model, relevant threats for the standard will be documented in the Security Considerations sections of the specification.

In general, the “Security Considerations” sections serve as notes on external security in a threat model, and the Threat Model document can be referred to in a Group Note.

There should be a clear description of the kinds of threats to the described technology.

This should be approached as an effort to perform threat modeling, describing all known or foreseeable risks and threats to potential implementers, users, and stakeholders.

Authors MUST describe:

1. The use case(s) and diagram(s), which assumptions are considered

2. The threats both in scope and out of scope (with the justification)

3. The response to each threat.

4. If a countermeasure is identified, the specification provides a reference, which, if accepted with justification, addresses the residual threat.

5. Threats the standards protect against, and threats that are accepted.

6. Residual risk to users, implementers, and related technologies

Please note that:

• If cryptography is used, please refer to the specific guidance with related threats.

• If some threats are “imported”, for example, from the ecosystem or other standards, these threats must be specified in the security consideration sections.

• If other threats are assumed to be addressed at another level of the Web Platform. This must be specified, and requirements for related technologies must be provided to keep the Web Platform secure.

To understand the threats and attacks that needed to be covered, please refer to:

• Appendix 4: Web APIs

• Appendix 5: File Formats

8. Acknowledgments

Several individuals contributed to the document. The editor especially thanks…

Appendix 1: Minimalist Threat Model for the World Wide Web

The World Wide Web (“the Web”) is built on many different technologies. Each of which is independently developed and maintained. This makes threat modeling for the Web a complex challenge (See The Web is Unversioned).

For this threat model, we think about the World Wide Web as just six independent components: three human (user, website admin, and network operator), and three in software (a browser, a DNS server, and a web server). This is an intentionally simplified view of the web so that we can focus on the threats inherent in a minimal instantiation of an SSL/TLS-secured World Wide Web.

A1.1 Visual Language

For our example in this Threat Modeling Guide, we use an intentionally simplified Data Flow Diagram (DFD) inspired by Adam Shostack (reference), which uses just six elements for clarity: external entities, processes, flows, data storage, data objects, and threat containers (which define threat boundaries).

External Entity (E)	An autonomous entity, external to the application, that interacts with, or drives, processes. Preferably a human user or legal person responsible for driving an interaction. Include all stakeholders, including the primary user as well as others who have designed roles in the system. Do not include attackers as they are treated as independent factors, exogenous to the model. In particular, be careful about over-characterizing attackers as it is impossible to cover all possible attacks and attackers. Assumptions about the limits of attacks and attackers can leave you open to unforeseen vulnerabilities. In contrast, we can completely characterize the system under attack in a visual diagram, no matter the nature or intention of any attacker.
Process (P)	A process within the system (e.g., feature in a component, component in an application, application in an operating system, operating system in a virtual machine).
Flow (F)	The mechanism by which data flows between elements. May be uni- or bi-directional. Data can flow between an external entity and a process, between one process and another, or between a process and a data store.
Data Store (S)	A medium for retaining information. This may be generic (e.g., local filesystem) or specific (e.g., configuration table in a database). It might be ephemeral, like a cache, or more permanent, like an archive.
Data Object (O)	A self-contained data object shared over data flow or stored in a data store. Transferrable between elements without losing integrity. Often secured by cryptographic signature.
Threat Boundary (B)	A boundary separating trust domains, where each trust domain is controlled by a single authority. When a threat boundary defines a closed loop, it defines a threat container.
Threat Container (C)	A collection of elements secured by a common authority. Elements within a container are taken to be operating within a threat boundary. Communications into or out of a threat container are recognized as crossing a threat boundary.

A1.2 Data Flow Diagram for Minimalist Web Threat Model

A1.3 Data Flow Description

For this diagram, consider the simplest realization of the world wide web including DNS and SSL/TLS.

In the intended use, a user (E1) interacts (F1) with a browser process (P1), which operates in its own container, the web browser (C1). This interaction directs the browser to display a specific URL as selected by the user. The browser process (P1) starts by resolving the domain name of that URL by requesting DNS resolution (F2) from a DNS resolver (P2), which returns an IP address for HTTP requests to that domain. This information is tracked as session data (F3) and stored in browser data storage (S1). Then, the browser sends HTTP requests (F4) to a server process (P3), which is running in its own container, the web server (C3). These requests (F4) are encrypted using SSL/TLS protocols. In response to requests (F4), the web server returns an SSL/TLS certificate (O1) and the resource requested, using its own server data storage (S2) to generate an appropriate response.

Supporting this operation are the Website Administrator (E2) and the (E3) Network Administrator, who keep the network-available services running.

Note: we do NOT model potential attackers, as over-characterizing attackers can lead to analysis bias that is better avoided.

It is understood that the browser process (P1) is likely realized as multiple processes running as software in an operating system on a device. Threat modeling for such details would suggest breaking both the process and its container (C1) into its subcontainers and processes, identifying the flows between each. However, in this threat model, we treat the web browser as just two elements, the browser process and its data storage.

Similarly, the web server (C3) is often realized not only as multiple processes, but often with data flows that communicate with multiple back-end systems in response to user requests. However, it is possible to realize the web server as a single process in a single container with its own local storage, which contains its SSL/TLS certificate. For our analysis, we choose this minimalist realization.

The DNS resolver also depends on external data flows that are beyond the scope of this threat model.

We treat the DNS Server and the Web Server as essentially black box elements which provide information in response to requests, but whose internals are intentionally outside the threat model. We are not evaluating the threats of the DNS system. Nor are we evaluating the threats of any particular back-end system or web server. These are external systems which may be worth noting as sources of threats, but whose definitions are beyond this scope.

A1.4 Data Flow Dictionary

From this diagram and its dictionary, we can begin to model relevant threats.

A1.5 Threats

The following sections describe the identified threats and potential responses to them.

A1.5.1 Target Threats

The TLS/SSL addition to the Web specifically addressed a handful of known problems.

T1. Imposter Websites (URL validation) T2. Network Surveillance (DH, Encryption) T3. Network Corruption (MAC signature) T4. Fraudulent Certificate (Signed Certificates)

A1.5.2 Implementation Threats

T5. Key Compromise T6. Library Compromise

A1.5.3 External Threats

T7. Quantum Cryptography Attacks T8. Harvest Attacks T9. Flawed Cryptosuite

A1.5.4 Dependency Threats

T9. TCP/IP

Appendix 2: Threat Analysis Frameworks

Every threat is a result of thinking about the system in a particular way. Several different analytical frameworks have been developed to help think about software and software systems in terms of harms, threats, and risks. Each framework inevitably defines its own terms, which together provide a coherent way to think about threats, but which might introduce term confusion. For example, “repudiation” means different things in the STRIDE framework than in LINDUN. To understand the vocabulary, it is helpful to anchor it to a particular framework.

At the W3C, we consider all variations of “threats” to be suitable for inclusion in a threat model, even if the source framework calls threats by a different name, with different nuance. This opens the aperture for threat modeling to any domain of concern the work group wants to consider. In fact, working groups should use whatever analytic frameworks most coherently describe the threats they are most concerned about.

Frameworks worth considering:

• Security Threats (STRIDE)

• Security Attacks (RFC 3552)

• Security/Privacy/Trust Controls (OSSTMM)

• Privacy Threats (LINDDUN)

• Privacy Threats (RFC 6973)

• Privacy/Security Threats (W3C Self-Review Questionnaire: Security and Privacy)

• Harms (Microsoft)

• Human Rights Considerations (RFC 9620)

Appendix 3: Web APIs

For Web APIs, at least the following forms of attack or threats MUST be considered:

• Abuse of functionality

• SOP relaxing

Please refer to:

• https://github.com/w3c/threat-model-web

• https://www.w3.org/TR/security-privacy-questionnaire/

• https://w3c.github.io/fingerprinting-guidance/

Appendix 4 File Formats

For file formats, at least the following forms of attacks or threats MUST be considered:

Appendix 5: Cryptography

Please refer to https://w3c.github.io/security-guidelines-cryptography/

9. References

9.1. Security and Web Platform

Alcorn, Wade, Christian Frichot, and Michele Orru (2014). The Browser Hacker’s Handbook. Hoboken, NJ: John Wiley & Sons. https://www.wiley.com/en-us/The%2BBrowser%2BHacker%27s%2BHandbook-p-9781118662090

Zalewski, Michal (2011). The Tangled Web: A Guide to Securing Modern Web Applications. San Francisco: No Starch Press. https://nostarch.com/tangledweb

9.2. Browsers

Barth, Adam, Collin Jackson, and Charles Reis (2008). “The Security Architecture of the Chromium Browser.” Stanford University. http://seclab.stanford.edu/websec/chromium/

Sutton, Tanya, ed. (2010). Web Browser Security: Evolving Threats, Safeguards, and the Road Ahead. Red Gate Software. https://www.red-gate.com/simple-talk/devops/security/web-browser-security/

Zalewski, Michal (2008). Browser Security Handbook. Google Inc. https://code.google.com/archive/p/browsersec/

Mozilla Foundation (2024). “Firefox Privacy and Security Features.” https://support.mozilla.org/en-US/products/firefox/privacy-and-security

Google Chromium Project (2023). “Secure Architecture.” https://www.chromium.org/developers/design-documents/security-architecture/

Reis, Charles, and the Chrome Team (2022). “Chrome Security Architecture – Process Level Snapshot.” Google Docs. https://docs.google.com/document/d/1uDQRGb1x3o7zIOycMqBv6zLULW8PKnA4/

Google Chromium Project (2021). “Multi-Process Architecture.” https://www.chromium.org/developers/design-documents/multi-process-architecture /

Google Chromium Project (2021). “Sandboxing.” https://chromium.googlesource.com/chromium/src/+/main/docs/design/sandbox.md

Fariello, Joaquin (2022). “How to Find Vulnerabilities in Web Browsers.” Google Docs. https://docs.google.com/document/d/1kKryOlsn-FindBrowserBugs

Web APIs

de Rossi, Alberto (2024). “Permissions.” https://albertofdr.github.io/permissions

9.3. Extensions

Bianchi, Antonio, Yanick Fratantonio, Christopher Kruegel, and Giovanni Vigna (2025). “A Study on Malicious Browser Extensions in 2025.” arXiv preprint arXiv:2503.01234. https://arxiv.org/abs/2503.01234

9.4. Threat Models

Allen, C. & Appelcline S. (2019). SmartCustody: Use of Advanced Cryptographic Tools to Improve the Care, Maintenance, Control, and Protection of Digital Assets. Smart Custody https://www.smartcustody.com/

Grigg, Ian (2012). “The Browser Threat Model.” https://iang.org/papers/browser\_threat\_model.html

W3C PING Group (2023). “Target Privacy Threat Model.” https://w3cping.github.io/privacy-threat-model/

W3C Web Payments Working Group (2022). “Payment Handler Privacy Threat Model.” https://w3c.github.io/payment-handler/privacy-threat-model.html

FIDO Alliance (2017). “FIDO Security Reference (Includes Threat Analysis and a Diagram).” https://fidoalliance.org/specs/fido-security-ref-v1.1-ps-20170202.html

9.5. Threats

W3C (2024). “Self-Review Questionnaire: Security and Privacy.” https://www.w3.org/TR/security-privacy-questionnaire/

W3C TAG (2024). “Mitigating Browser Fingerprinting in Web Specifications.” https://www.w3.org/TR/fingerprinting-guidance/

KeepAware Labs (2024). “Most Common Browser Threats in 2024: An Overview of Attack Mechanisms and Impacts.” https://keepaware.com/browser-threats-2024/

Al Ani, Hasan, et al. (2023). “Fingerprinting and Tracing Shadows: The Development and Impact of Browser Fingerprinting on Digital Privacy.” arXiv preprint arXiv:2310.04567. https://arxiv.org/abs/2310.04567

XS-Leaks Project (2024). “XS-Leaks Wiki.” https://xsleaks.dev/

Fernandez-de-Retana, Alberto (2024). “Tracking.” https://albertofdr.github.io/tracking