Merge branch 'new-clause-4' into 'main_publish'

<span id="_ref_i.9"></span><a name="#_ref_i.9">[i.9]</a>[Mixed Content (W3C Candidate Recommendation Draft)](https://www.w3.org/TR/mixed-content/), W3C, 23 February 2023

<span id="_ref_i.10"></span><a name="#_ref_i.10">[i.10]</a>[Threat Model for the Web (W3C Editor's Draft)](https://w3c.github.io/threat-model-web/), W3C, 11 May 2026

<span id="_ref_i.11"></span><a name="#_ref_i.11">[i.11]</a>[HTML (WHATWG Living Standard)](https://html.spec.whatwg.org/multipage/), WHATWG, 11 May 2026

<span id="_ref_i.12"></span><a name="#_ref_i.12">[i.12]</a>[Fetch (WHATWG Living Standard)](https://fetch.spec.whatwg.org/), WHATWG, 08 May 2026

<span id="_ref_i.13"></span><a name="#_ref_i.13">[i.13]</a>[Content Security Policy Level 2 (W3C Reccomendation)](https://www.w3.org/TR/CSP2/), W3C, 15 December 2016

<span id="_ref_i.14"></span><a name="#_ref_i.14">[i.14]</a>[Secure Contexts (W3C Candidate Reccomendation Draft)](https://www.w3.org/TR/secure-contexts/), W3C, 10 November 2023

<span id="_ref_i.15"></span><a name="#_ref_i.15">[i.15]</a>[Subresource Integrity (W3C Working Draft)](https://www.w3.org/TR/sri-2/), W3C, 20 March 2026

<span id="_ref_i.16"></span><a name="#_ref_i.16">[i.16]</a>[RFC 8996: Deprecating TLS 1.0 and TLS 1.1](https://datatracker.ietf.org/doc/html/rfc8996), IETF, March 2021

<span id="_ref_i.17"></span><a name="#_ref_i.17">[i.17]</a>[RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile](https://datatracker.ietf.org/doc/html/rfc5280), IETF, May 2008

<span id="_ref_i.18"></span><a name="#_ref_i.18">[i.18]</a>[RFC 6962: Certificate Transparency](https://datatracker.ietf.org/doc/html/rfc6962), IETF, June 2013

<span id="_ref_i.n"></span><a name="_ref_i.n">[i.n]</a> &lt;Standard Organization acronym> &lt;document number> (&lt;version number>): "&lt;Title>".

<mark>Editor's Note: The EC advises that the references between verticals should be informative.</mark>  

<mark>Editor's Note: This clause is not normative.</mark>

## 4.0 Introduction

## 4.1 Product Functions

## 4.1 Intended Purpose

The intended purpose of standalone and embedded web browsers is to access and interact with the shared World Wide Web. This access includes everything from reading the news and online encyclopedias to accessing critical systems related to finance, government, healthcare, etc.

The intended purpose of a web browser is to access, retrieve, and render web-based resources on behalf of an end user and display them via a Graphical User Interface. This includes everything from reading the news and online encyclopedias to accessing critical systems related to finance, government, healthcare, etc.

Browsers are general purpose software: When presented with a web browser, including an embedded one, user expectations are generally that they can trust it as their "user agent" to do any internet-related task which they can access -- which, via links and other navigation mechanisms, expands to the whole web.

Browsers are general-purpose software: When presented with a web browser, including an embedded one, user expectations are generally that they can trust it as their user agent to mediate the interaction between them and the web.

The breadth of reasonably forseeable uses for all web browsers implies that there are many risks in common across use cases.

## 4.2 Product Architecture

### 4.1.1 Essential Functions

To access websites and make them available to users, web browsers need components to handle the following:

- Networking (including HTTPS and TLS)

- HTML interpretation and rendering

- CSS layout

- JavaScript and WebAssembly code execution

> NOTE: Java™ is the trade name of a programming language developed by Oracle Corporation.

- Image decoding

- SVG, MathML rendering

- GPU use, both to support rendering of HTML+CSS and for WebGPU

- Multimedia and video conferencing

- Camera, microphone and geolocation

- Retrieve web Content

- Parse HTML and build DOM

- Style CSS and compute resource layout

- Execute JavaScript and WebAssembly

- Render images, media, and other embedded content

- Manage navigation and sessions

- Establish client-server connections

- Store data

- Receive and process user input

- Deliver and apply software updates

TODO: Describe how these are put together, typical process architectures, include a diagram, etc.

> NOTE: Java™ is the trade name of a programming language developed by Oracle Corporation.

## 4.3 Operational Environment

## 4.2 Product Architecture

### 4.3.1 General description

The specific architecture of web browsers can vary based on factors such as vendor-specific implementation and use cases. This section focuses on the functionalities and trust boundaries of web browsers that have significant security implications. The following high-level Data Flow Diagram (DFD) elaborates on the DFD presented in W3C Threat Model for the Web [\[i.10\]](#_ref_i.10).

A web browser may be used on any device which supports a user interface and sufficient resources to run the browser. This includes desktop and laptop computers, mobile phones, smart televisions, certain embedded devices, etc.

<figure id="threat-model">

    <img src="./media/DFDGeneral.drawio.svg">

    <figcaption>Data Flow Diagram (DFD)</figcaption>

</figure>

Different contexts where web browsers are used may have different risk profiles, for example:

- **Privileged web browser process.** The Privileged web browser process is the initial process launched by the OS and is typically responsible for managing subsequent processes, sessions, navigation, User Interface, and policies. This high-privilege process also generally serves as a central broker for permissions and other OS APIs, as well as access to local resources and OS filesystem (It is worth noting that, in some implementations, these functions may not be carried out by the privileged web browser process alone but might instead be assigned to multiple processes). With direct OS access and elevated privileges, the Privileged web browser process enforces the trust boundary between the OS and the web browser itself.

- **web-content execution.** Web resources are parsed and executed inside dedicated child processes. These processes handle untrusted web resources and should therefore be modeled under the assumption that the input they receive and interpret cannot be trusted. For this reason, each website is typically assigned a dedicated sandboxed process that is isolated from all others. The resulting trust boundary separates web-executed content from the privileged web browser process.

- **Storage services.** Web browser typically also isolate and separate storage by origin. This includes cache, site data, session data, cookies, user credentials, and any other type of persistent or session-specific storage. This separation enforces the trust boundary between each origin-specific storage, preventing any origin from accessing another's stored data.

- **I/O.** Modern web browsers typically also isolate helper functionalities such as, networking stack, and other utilities into separate isolated processes to improve security and reliability.

- Use of a browser embedded within a social media application, for external links

- Consumer use on a personal computer or smartphone

- "Enterprise" desktop/laptop computers within the context of an undertaking (including critical infrastructure)

## 4.3 Operational Environment

### 4.3.2 Physical/Hardware environment

Web browser serve as a medium for interaction between a system and the web, retrieving web resources and executing them client-side. Because of this, the operational environment in which they operate assumes that the resources they handle are inherently untrusted.

### 4.3.3 Logical/Software environment

### 4.3.1 Security Functions

### 4.3.4 Connectivity aspects

Regardless of use cases, vendor-specific implementations, and browser architecture specifics, all products with digital elements classified as web browsers that fall within the scope of the present document should provide the security functions laid out in this section.

The security functions of a web browser include:

## 4.4 Distribution of Security Functions

- **Same Origin Policy.** A security function whereby scripts from one origin cannot access, read or manipulate data from another origin, as described in WHATWG HTML Living Standard [\[i.11\]](#_ref_i.11), and WHATWG Fetch Living Standard [\[i.12\]](#_ref_i.12).

- **Controlled relaxation of SOP.** A security property whereby the Same Origin Policy can be relaxed based on server-defined policies, for example, in accordance with Cross Origin Resource Sharing as defined in WHATWG Fetch Living Standard [\[i.12\]](#_ref_i.12).

- **Web content execution isolation.** A security property whereby web content from different origins is isolated into separate execution contexts.

- **Web resource content restriction.** A security control used to declare a set of content restrictions for a web resource as defined in W3C Content Security Policy Level 2 [\[i.13\]](#_ref_i.13) and successor standards.

- **Isolation and sandboxing.** A security function whereby browser components are sandboxed and operate with minimal OS privileges in accordance with the principle of least-privilege, and logical isolation is enforced between different components (such as sites and execution contexts).

- **Permission management of powerful features.** A security function whereby access to powerful features, as defined in W3C Secure Contexts [\[i.14\]](#_ref_i.14), is mediated through a permission system that requires express user permission.

- **Web resource integrity verification.** A security function whereby the integrity of retrieved web resources is verified at web browser level, in accordance with the Subresource Integrity feature defined in W3C Subresource Integrity [\[i.15\]](#_ref_i.15).

- **Automated updates.** An security feature whereby the rollout of security updates is automated, ensuring that vulnerabilities are remediated in a timely manner.

- **TLS enforcement.** A security function that enforces support for current TLS versions as defined by IETF RFC 8446 [\[i.7\]](#_ref_i.7) and successor standards, and the rejection of connections which use protocol versions identified as deprecated in IETF standards track RFCs, including RFC 8996 [\[i.16\]](#_ref_i.16) and successor standards.

- **Certificate validation.** A security function that includes validation of certificate chains, including certificate path as defined in IETF RFC 5280 [\[i.17\]](#_ref_i.17), and enforces Certificate Transparency as defined in IETF RFC 6962 [\[i.18\]](#_ref_i.18).

<mark>This clause should address supply chain and integration issues - when a product contains another or is combined with another. The clause should explain in an informative manner how the security functions are distributed across the components included in the product. However, how to address this issue is still not consistent across draft verticals.</mark>

### 4.3.2 Distribution of Security Functions

<mark>- Formulation of requirements (see C IoT verticals)??</mark>

The aforementioned security functions inform the product-specific security requirements laid out in Clause 5.

<mark>- Assumptions about the integration environment??</mark>

For each security function, a web browser may:

<mark>- What recommendation we make for due diligence on integrated components?</mark>

- **Provide it itself.** In this case, the security function is provided as a native component within the web browser’s codebase.

- **Require that it be provided by other parts of its context.** In this case, the browser delegates the provision of security functions to other components within its execution environment.

### 4.4.1 Security functions provided outside the product

### 4.3.3 Security functions provided outside the product's context

Across browsers and operating systems, different choices are made in different contexts about what is provided by the browser and what is implemented in the surrounding operating system and system libraries, with security functions performed at those other levels. For example:

Across web browsers and operating systems, different choices are made in different contexts about what is provided by the web browser and what is implemented in the surrounding operating system and system libraries, with security functions performed at those other levels. These may include for example:

- Some standalone browsers (e.g., on mobile platforms) are implemented with the use of a platform-provided embedded browser, subsuming most security functions

- Some standalone browsers (e.g., on mobile platforms) are implemented with the use of a platform-provided embedded browser, subsuming most security functions.

- Networking, including certificate validation and management, selection of algorithms, TLS broadly, etc.

- Image decoding, text rendering and Unicode handling (no inherent security function, but a historical source of exploitable vulnerabilities)

- Integrated password manager (may also be provided via an extension)

- Handling links which may be interpreted as references to native applications, whether via OS-registered origins or custom schemes

- Scoping permission to access camera, microphone, geolocation or other sensitive information

- etc. (This is list is not exhaustive.)

- Image decoding, text rendering and Unicode handling (no inherent security function, but a historical source of exploitable vulnerabilities).

- Integrated password manager (may also be provided via an extension).

- Handling links which may be interpreted as references to native applications, whether via OS-registered origins or custom schemes.

- Scoping permission to access camera, microphone, geolocation or other sensitive information.

- Web processes isolation may be enforced at OS kernel level.

In such cases, when functionality is implemented outside of the browser in such system libraries or operating systems, the responsibility for handling the risk is transferred to this library, following a risk assessment by the browser which integrates the OS/library that this is reasonable.

### 4.4.2 Security functions provided to other components

### 4.3.4 Security functions provided to other components

Web browsers provide a secure, trustworthy environment to render websites, which may be used as part of other products.

This property makes the web an ideal low-risk way to deliver application user interfaces.

## 4.5 Users

## 4.4 Users

Almost all computer users interact with web browsers at some point. This includes:

Almost all computer users interact with web browsers at some point. Users may include for example:

- General public

- Children, students

- Children and protected users

- Vulnerable adults

- Users of the web with respect to sensitive data

- Professionals in all fields of work

- Workers in critical infrastructure

- Users with accessibility needs

- Enterprise administrators

- Developers and technical users

## 4.6 Use Cases

## 4.5 Use Cases

### 4.6.1 Standalone browser use cases

This list is non-exhaustive, but this standard provides mitigations to risks for the following use cases:

### 4.5.1 Standalone browser use cases

**UC-CONS**: Standalone web browser for individual consumers

- Used for accessing the whole web, including sensitive/critical applications.

- Users are, in general, not educated or aware of cybersecurity issues.

- Installed on mobile phones, desktop and laptop computers, televisions, larger embedded devices, etc.

- Includes flexible settings, including high-risk features like developer mode, etc.

**UC-INST**: Standalone web browser for institutional or enterprise use, including critical infrastructure

- Central IT administration may set "enterprise policy" to configure security-related policies.

- Used in environments which are often taking other sorts of precautions, e.g., at the network/VPN level, physical access, etc.

- May be used to access "internal" websites which may have been developed with more or less attention to security, or which have special authentication needs.

### 4.6.2 Embedded browser use cases

### 4.5.2 Embedded browser use cases

**UC-ETAB**: Browser-like tab component for embedding in a larger application

- Used by embedding applications to enable linking to outside content while encouraging the user to return to the parent application

- Intended to facilitate access to just one website, omitting any UI to enter URLs or searches

- Grants access via links to the rest of the World Wide Web; users may "forget" that they are inside another application

- Typically no settings UI, and no integration into enterprise policy.

- Could share the state with the user's default browser.

- Could share the state with the user's default browser

# 5. Technical requirements for the Products

<mark>Editor's Note:This is the normative clause of the standard, defining the technical requirements to implement the Essential Security Requirements of the CRA regulation. The text of the regulation shall never be copied or interpreted in the standard.</mark>

# Annex B (informative): Cybersecurity threat landscape, risk identification and assessment methodology

This Annex applies a "state of the art" risk assessment methodology to the Product in scope of the present document, to identify threats, evaluate the risks and define security profiles applicable to the different use cases of the product context.

This Annex applies a "state of the art" risk assessment methodology to the Product in scope of the present document, to identify threats, evaluate the risks and define security profiles applicable to the different use cases of the product context. Threat elicitation is supported by a Data Flow Diagram of each product use case identified in Clause 4, namely: Consumer web browsers, Enterprise web browsers, and Embedded web browsers.   

Consider defining a common sub-structure.

## Asset Inventory

# Annex C (informative): Relationship between the present document and any related ETSI standards (if any, e.g. EN 303 645)