EN-304-617.md.backup

<div align="center">
**ETSI EN 304-617 {{VERSION}} ({{YEAR}}-{{MONTH}})**
</div>

![~~CAPTION~~](media/etsi-coverpage-logo.png)
HARMONISED EUROPEAN STANDARD  
CYBER; CRA; <br />
Essential cybersecurity requirements for Browsers 


<div style="text-align: center;">
Reference<br />
&lt;Workitem><br />
Keywords<br />
&lt;keywords><br />

ETSI<br />
650 Route des Lucioles<br />
F-06921 Sophia Antipolis Cedex - FRANCE<br />
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16<br />
Siret N° 348 623 562 00017 - APE 7112B<br />
Association à but non lucratif enregistrée à la<br />
Sous-préfecture de Grasse (06) N° w061004871<br />
</div>



**_Important notice_**

The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI deliverable is the one made publicly available in PDF format on [ETSI deliver](ETSI deliver) repository.

Users should be aware that the present document may be revised or have its status changed, this information is available in the [Milestones listing](Milestones listing).

If you find errors in the present document, please send your comments to the relevant service listed under [Committee Support Staff](Committee Support Staff).

If you find a security vulnerability in the present document, please report it through our [Coordinated Vulnerability Disclosure (CVD)](Coordinated Vulnerability Disclosure (CVD)) program.

**_Notice of disclaimer & limitation of liability_**

The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of experience to understand and interpret its content in accordance with generally accepted engineering or other professional standard and applicable regulations.

No recommendation as to products and services or vendors is made or should be implied.

No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness for any particular purpose or against infringement of intellectual property rights.

In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use of or inability to use the software.

<br />

**_Copyright Notification_**

No part may be reproduced or utilised in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorised by written permission of ETSI. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media.

&copy; ETSI yyyy.

All rights reserved.<br />

</div>

# Contents

<br />

# Intellectual Property Rights

Essential patents

IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations pertaining to these essential IPRs, if any, are publicly available for **ETSI members and non-members** , and can be found in ETSI SR 000 314: _"Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards"_ , which is available from the ETSI Secretariat. Latest updates are available on the [ETSI IPR online database](https://ipr.etsi.org/).

Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.


Trademarks

The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners. ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.

**DECT&#8482;**, **PLUGTESTS&#8482;**, **UMTS&#8482;** and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. **3GPP&#8482;**, **LTE&#8482;** and **5G&#8482;** logo are trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. **oneM2M&#8482;** logo is a trademark of ETSI registered for the benefit of its Members and of the oneM2M Partners. **GSM&#174;** and the GSM logo are trademarks registered and owned by the GSM Association.

# Foreword

> DRAFT FOREWORD - DO NOT CONSIDER THE CONTENT

This draft Harmonised European Standard (EN) has been produced by ETSI Technical Committee Cyber Working Group for EUSR (CYBER-EUSR), and is now submitted for the combined Public Enquiry and Vote phase of the ETSI Standardisation Request deliverable Approval Procedure (SRdAP).

```
The present document has been prepared under the Commission's standardisation request C(2025) 618 final to provide one voluntary means of conforming to the requirements of Regulation (EU) No 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) No 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act).
```

Once the present document is cited in the Official Journal of the European Union under that Regulation, compliance with the normative clauses of the present document given in table A.1 confers, within the limits of the scope of the present document, a presumption of conformity with the corresponding requirements of that Regulation and associated EFTA regulations.

Transposition table

The Harmonised Standard shall have appropriate transposition periods specified. A Harmonised Standard confers presumption of conformity when it has been published in the Official Journal of the European Union (OJEU) and transposed by a member state.

The Technical Body may propose different dates to the default ones (3, 6, 18). Technical Bodies who wish to propose different dates are advised to indicate this clearly in the approved committee draft.

| Proposed national transposition dates                          |                                 |
|----------------------------------------------------------------|---------------------------------|
| Date of latest announcement of this EN (doa):                  | 3 months after ETSI publication |
| Date of latest publication of new National Standard            |                                 |
| or endorsement of this EN (dop/e):                             | 6 months after doa              |
| Date of withdrawal of any conflicting National Standard (dow): | 18 months after doa             |

The Technical Body should advise the ETSI Secretariat if the above default national transposition dates are inappropriate for the particular standard.



# Modal verbs terminology

In the present document "**should** ", "**should not** ", "**may** ", "**need not** ", "**will** ", "**will not** ", "**can** " and "**cannot** " are to be interpreted as described in clause 3.2 of the [ETSI Drafting Rules](https://portal.etsi.org/Services/editHelp/How-to-start/ETSI-Drafting-Rules) (Verbal forms for the expression of provisions).

"**must** " and "**must not** " are **NOT** allowed in ETSI deliverables except when used in direct citation.

# Executive summary


Browsers represent one of the most complex and security-critical software products in modern computing, serving as the primary gateway between users and internet resources while processing untrusted content from millions of sources daily. The browser's architecture encompasses multiple interconnected subsystems - including rendering engines, JavaScript/WebAssembly execution environments, network stacks, and extension frameworks, each presenting distinct attack surfaces that shall be defended while maintaining performance, compatibility with legacy web content, and user autonomy.

Unlike traditional security products that can enforce restrictive controls, browsers shall balance protection against an evolving threat landscape with respect for user choice, creating unique challenges where users may deliberately choose to visit malicious sites, install risky extensions, or disable security features. The browser's multi-layered trust model, spanning from the highly privileged browser core through semi-trusted extensions to completely untrusted web content, requires sophisticated isolation mechanisms, granular permission systems, and careful mediation of system resource access. 

Given browsers' ubiquitous deployment across consumer, enterprise, and specialized environments, their role as platforms for Progressive Web Applications, and their position as primary targets for nation-state and criminal actors, establishing proportionate security requirements under the Cyber Resilience Act demands careful consideration of the inherent tensions between security, functionality, performance, and user agency that define the modern web browsing experience.

# Introduction

This European harmonised standard defines cybersecurity requirements applicable to browsers.

This document will provide security requirements and assessment criteria covering all elements defined in CRA Annex I Part 1 and Part 2 for stand alone browsers, as mentioned in CRA Annex III Class I important products.
This work item intends to produce an EN as candidate for harmonisation, under the standardisation request in support of the implementation of the CRA (M/606).

<br />

# 1 Scope

This standard focuses on browsers, both standalone and embedded. Browsers are software products with digital elements that enable end users to access and interact with web content hosted on servers that are connected to local and remote networks.

Within the context of an operating system, browsers are user-applications with a primary function and probable daily use. They are often leveraged as means of accessing remote authentication (single-sign-on) or even as a bridge (deep-link) to another application that has already been installed. In both cases, all systems have the notion of a “default browser” that can then be instrumented by other applications to navigate to a website or perform such an activity.

The activity of browsing can be defined in the following steps:

1. A machine accesses remote resources and source code, such as HTML, JavaScript/WebAssembly, and CSS.
2. This source is represented visually, acoustically, or in some other form.
3. The user interacts with the rendered representation through input and output interfaces, including visual observation, text entry, pointer interaction, or other supported input modalities.

## 1.1	Browser 

### 1.1.1	Standalone

Standalone browsers are applications that fulfil the functions of browsing.

Web browsers are software applications that access, retrieve, and interact with information and resources addressed by URLs. A standalone browser may be used for everyday tasks such as reading email, managing a calendar, or consuming the news. 

Such programs commonly have interfaces for managing multiple websites, browsing history, bookmarks, user identities, passwords, and other settings. 

They can commonly be extended with browser extensions, which are products with digital elements that have the ability to read, store, and modify the websites that users interact with.

### 1.1.2 Embedded

Embedded browsers are browsing services that are integrated into another system or application. 

As such, they are programs using the same baseline technology of browsing but are commonly used for “single purpose” browsing. This means that instead of opening the user’s preferred standalone browser, the hosting application will open an embedded browser to keep the user’s attention. It is not common for a user to be able to change the configuration of an embedded browser.

### 1.1.3 Progressive Web Apps (PWA)

Progressive Web Apps are web applications that can be installed to a user's device from a standalone browser and subsequently operate in a dedicated application-like context.

PWAs leverage browser capabilities including service workers, application manifests, and isolated storage to provide offline functionality, push notifications, and integration with operating system features such as the application launcher and task switcher. When installed, they execute within the browser's process architecture but present themselves to the user as distinct applications with their own windows, icons, and settings.

Unlike traditional web pages, installed PWAs maintain separate configuration contexts from the main browser, including distinct storage partitions, permission grants, and display modes. They may register custom protocol handlers, manage their own cache strategies through service workers, and receive operating system events such as share targets or file handlers. Despite this application-like presentation, PWAs remain fundamentally web applications subject to the same security boundaries and web platform APIs as content rendered in standard browser tabs.

### 1.1.4 Browser Extensions

Browser extensions are third-party software components that integrate with and extend the functionality of standalone browsers.

Extensions operate with elevated privileges compared to standard web content, enabling them to intercept and modify network requests, inject scripts into web pages, access cross-origin resources, interact with browser APIs, and persist data across browsing sessions. They are distributed through vendor-operated extension stores or side-loaded through developer modes, and are subject to varying degrees of review, validation, and ongoing monitoring depending on the browser vendor's policies.

Unlike web applications that execute within the constraints of the same-origin policy, extensions declare their required permissions through manifest files and, once granted, operate with capabilities that span multiple origins and browser contexts. They may consist of background scripts or service workers for persistent logic, content scripts that execute within web page contexts, popup interfaces, options pages, and other components. The security model of extensions creates a unique trust boundary where extensions act as intermediaries between the browser core and web content, requiring careful permission management, isolation mechanisms, and code signing to prevent abuse while enabling legitimate functionality enhancements.

## 1.2 Derivative Browsers and Manufacturer Obligations

A significant proportion of browsers placed on the market are derivative products based on open source browser engines or substantially complete browser implementations. Understanding the manufacturer's obligations for such derivative products is essential to the proportionate application of this standard.

### 1.2.1 Open Source Browser Engines and Derivative Products

Open source browser projects such as Chromium, Gecko (Firefox), and WebKit provide complete or near-complete browser implementations that serve as the foundation for derivative products. These upstream projects are stewarded by organizations that maintain the core rendering engines, JavaScript execution environments, network stacks, and security architectures, but the projects themselves do not constitute products placed on the EU market with CE marking.

When an economic operator takes such an open source project, applies modifications (whether substantial or minor), and places the resulting browser on the market under their own brand or distribution channel, that operator becomes a manufacturer under the Cyber Resilience Act <a name="_ref_i.1">[i.1]</a>. This classification applies regardless of the extent of modification - from minor branding and default configuration changes to substantial feature additions, custom user interfaces, or integration of proprietary services.

### 1.2.2 Spectrum of Derivative Modifications

Derivative browsers exist along a spectrum of modification, each with implications for conformity assessment:

**Minor Modifications**: Browsers that modify only branding elements, default search providers, homepage settings, bundled bookmarks, or visual themes while maintaining the upstream codebase's security architecture, update mechanisms, and core functionality. Examples include rebranded releases for specific markets or partnerships.

**Configuration-Level Modifications**: Browsers that alter default privacy settings, tracking protection levels, extension policies, or feature flags to differentiate the product while preserving the underlying implementation. Such modifications may strengthen or weaken security postures relative to the upstream project.

**Feature Additions**: Browsers that integrate additional capabilities such as built-in VPN services, cryptocurrency wallets, AI assistants, proprietary synchronization services, or vertical-specific toolbars. These additions create new attack surfaces and data processing considerations beyond those present in the upstream project.

**Architectural Modifications**: Browsers that modify process architecture, sandbox implementations, network request routing, certificate validation logic, or other security-critical components. Such changes may fundamentally alter the security properties inherited from the upstream project.

### 1.2.3 Manufacturer Responsibilities for Derivative Products

Economic operators placing derivative browsers on the market bear full manufacturer obligations under the CRA, regardless of their reliance on upstream security implementations. These obligations include:

**Security Requirement Compliance**: Demonstrating that the derivative product, in its modified form, satisfies the essential cybersecurity requirements of Annex I of the CRA. While manufacturers may rely on the security properties of unmodified upstream components, any modifications should be assessed for their impact on those security properties.

**Vulnerability Management**: Establishing processes to monitor both upstream security advisories and vulnerabilities specific to the manufacturer's modifications. Timely integration of upstream security patches is a critical manufacturer responsibility, as delays in patch integration extend the exposure window for known vulnerabilities affecting end users.

**Conformity Assessment**: Conducting or commissioning technical assessments that address both the inherited security properties from the upstream project and the security implications of the manufacturer's specific modifications. The assessment should consider whether modifications have weakened, maintained, or strengthened the security posture.

**Technical Documentation**: Maintaining documentation that clearly delineates which components are inherited from the upstream project versus manufacturer modifications, security reviews conducted on modifications, processes for integrating upstream updates, and any divergences from upstream security defaults.

**Update Delivery**: Ensuring that security updates reach end users in a timely manner. For derivative browsers, this includes both the integration of upstream security patches into the manufacturer's codebase and the delivery of updated builds to end users through the manufacturer's distribution and update infrastructure.

### 1.2.4 Trust in Upstream Security Implementations

Manufacturers of derivative browsers commonly rely on the security implementations provided by upstream projects for foundational requirements such as TLS protocol implementation, cryptographic library usage, certificate validation, same-origin policy enforcement, and sandbox architecture. This reliance is reasonable provided that:

**Upstream Security Processes are Verifiable**: The upstream project demonstrates transparent security practices including public vulnerability disclosure, security-focused development processes, regular security audits, and timely patch releases.

**Modifications Do Not Undermine Upstream Security**: The manufacturer's changes do not bypass, weaken, or interfere with the security mechanisms inherited from the upstream project. For example, modifications that disable certificate validation, weaken content security policies, or reduce sandbox restrictions would constitute substantial security regressions requiring additional justification and compensating controls.

**Integration Timeliness is Maintained**: The manufacturer maintains a process to integrate upstream security patches within a reasonable timeframe. Extended delays between upstream patch availability and manufacturer distribution create unnecessary risk exposure for end users.

**Deviation Points are Documented and Assessed**: Where the manufacturer intentionally diverges from upstream security defaults (e.g., enabling features disabled upstream for security reasons, or modifying cryptographic configurations), these deviations are documented with security rationale and risk assessment.

### 1.2.5 Application of This Standard to Derivative Browsers

When applying the requirements of this standard to derivative browsers, manufacturers and assessors should consider:

**Inherited vs. Modified Components**: Requirements addressing components that remain unmodified from the upstream project may be satisfied by demonstrating that the upstream implementation meets the requirement, provided the manufacturer's integration does not interfere with that implementation.

**Modification-Specific Assessment**: Requirements addressing areas where the manufacturer has made modifications require direct assessment of those modifications. This includes manufacturer-added features, modified defaults, integrated services, and any changes to security-critical code paths.

**Update Mechanism Obligations**: Even where a manufacturer relies on the upstream project's update mechanism architecture, the manufacturer remains responsible for ensuring that updates reach end users. This includes operating update servers, signing update packages, managing update channels, and ensuring update delivery reliability.

**Use Case Alignment**: Derivative browsers should be assessed against the use cases (Chapter 4.4) that align with their intended deployment contexts. A derivative browser marketed for general consumer use would align with UC-B1, while one marketed for enterprise deployment with proprietary features would align with UC-B7, regardless of their shared upstream heritage.

Derivative browsers represent a practical and economically significant category of products within the browser market. This standard recognizes that reliance on well-maintained upstream security implementations is a valid engineering approach, while maintaining that manufacturers placing derivative products on the market retain full responsibility for the security properties of the products they distribute.

### 1.2.6 State of the Art: Industry Testing and Security Practices

The state of the art for browser development and security validation encompasses organizational practices, industry standards, and comprehensive testing regimes that manufacturers should demonstrate to establish the quality and security of their browser implementations, whether original or derivative.

**Organizational Practices and Resources**:

Reputable browser manufacturers, both upstream projects and derivative product vendors, demonstrate their commitment to security through:

- **Adequate staffing**: Employment of sufficient numbers of developers and security personnel with expertise in browser architecture, web standards, cryptography, and vulnerability research
- **Security-focused development**: Dedicated security teams, secure development lifecycle practices, code review processes, and security architecture oversight
- **Transparency and communication**: Public disclosure of security policies, vulnerability handling procedures, and regular security bulletins
- **User commitment**: Published statements of commitment to user security and privacy, including privacy policies, data handling practices, and user control mechanisms
- **Update cadence**: Regular release schedules for security updates and patches, with clear timelines for critical vulnerability remediation

**Industry Standards Compliance**:

Browsers are expected to comply with applicable industry standards including but not limited to:

- **Web standards**: W3C specifications (HTML, CSS, JavaScript/ECMAScript, DOM, Fetch, etc.), WHATWG living standards
- **Security standards**: IETF RFCs for TLS, HTTP, WebAuthn, and related protocols; CA/Browser Forum Baseline Requirements
- **Accessibility standards**: WCAG (Web Content Accessibility Guidelines), ARIA (Accessible Rich Internet Applications)
- **Privacy standards**: Do Not Track, Global Privacy Control, tracking protection standards

**Industry-Recognized Testing Frameworks**:

Browsers should undergo testing using recognized industry test suites and frameworks:

**Standards Conformance Tests**:

- **Web Platform Tests (WPT)**: Comprehensive cross-browser test suite maintained by W3C and browser vendors, with public dashboard available at https://wpt.fyi/ showing conformance across implementations
- **Test262**: Official ECMAScript conformance test suite maintained by Ecma TC39, verifying JavaScript/ECMAScript specification compliance
- **W3C Test Suites**: Individual test suites for specific W3C specifications (CSS Working Group tests, HTML5 tests, etc.)
- **Acid Tests**: Historical but influential browser standards compliance tests (Acid1, Acid2, Acid3) developed by the Web Standards Project

**Functional and Compatibility Testing**:

- **Selenium**: Open-source testing framework for browser automation, widely used for functional testing and regression testing across browsers
- **BrowserStack**: Cloud-based cross-browser testing platform enabling compatibility verification across browser versions, operating systems, and devices
- **Playwright/Puppeteer**: Modern browser automation and testing frameworks providing programmatic control for automated testing

**Security-Specific Testing and Validation**:

- **CA/Browser Forum participation**: Engagement with the CA/Browser Forum (https://cabforum.org/working-groups/server/charter/) which establishes baseline requirements for certificate authorities and browser trust store policies
- **TLS/Certificate validation testing**: Testing against standard certificate validation scenarios, revocation checking, and TLS protocol compliance
- **Vulnerability disclosure programs**: Participation in responsible disclosure programs, bug bounty programs, and coordinated vulnerability disclosure processes
- **Penetration testing**: Regular security assessments by internal security teams or external security researchers

**Standards Body Participation**:

Active participation in standards bodies demonstrates commitment to interoperability and security best practices:

- **W3C (World Wide Web Consortium)**: Participation in working groups defining web standards
- **WHATWG (Web Hypertext Application Technology Working Group)**: Collaboration on living standards for HTML, DOM, and related specifications
- **IETF (Internet Engineering Task Force)**: Engagement in protocol standardization (TLS, HTTP, WebRTC, etc.)
- **Ecma International**: Participation in ECMAScript (JavaScript) standardization through TC39
- **CA/Browser Forum**: Involvement in establishing requirements for certificate authorities and browser root programs
- **FIDO Alliance**: Participation in authentication standards development (WebAuthn, FIDO2)

**Implications for Derivative Browsers**:

Derivative browser manufacturers should demonstrate:

1. **Upstream testing inheritance**: Evidence that the upstream project undergoes comprehensive testing via WPT, Test262, and other industry-standard test suites, with results publicly available
2. **Modification testing**: Testing of manufacturer-specific modifications using appropriate test frameworks to ensure modifications do not introduce regressions or security vulnerabilities
3. **Integration testing**: Validation that the integration of upstream components with manufacturer additions maintains standards compliance and security properties
4. **Security review process**: Documentation of security review procedures for modifications, including code review, security testing, and vulnerability assessment
5. **Update testing**: Verification that upstream updates are tested before distribution to ensure compatibility with manufacturer modifications

Manufacturers may demonstrate compliance with industry testing practices by referencing:

- Publicly available test results on wpt.fyi or similar dashboards
- Participation in open-source testing efforts
- Documentation of testing methodologies and results
- Third-party security assessments or certifications
- Membership in relevant standards bodies and working groups

The state of the art represents a comprehensive approach to browser quality and security, combining organizational commitment, standards compliance, extensive automated testing, security-focused practices, and community engagement. Derivative browser manufacturers should demonstrate that their products meet or exceed these industry norms, either through inheritance from well-maintained upstream projects or through their own testing and validation processes.

# 2 References

## 2.1 Normative references

_**In Harmonised Standards these references shall be specific** (identified by date of publication and/or edition number or version number) **publicly available and in English, except in exceptional circumstances making sure that impacts have been evaluated and explanations have been given on how any negative implications should be avoided** . See clauses 2.10.1 and 8.4 of the [EDRs](EDRs) and the communiqu&eacute; on "[References in ETSI Deliverables](https://portal.etsi.org/Portals/0/TBpages/edithelp/Docs/News_from_editHelp/References_in_ETSI_deliverables.pdf)"._

_Guidance for selecting normative references in harmonised standards is given in clause 2.8.3 of the Vademecum on European standardisation. Please **systematically consult with your Technical Officer** for the latest guidance on normative references other than to ENs, ISO/IEC standards, notably to prevent the risk of non-acceptance._

_**Legal acts can never be used as normative references.**_

_It is recommended that the number of references be limited to the minimum needed for the implementation/application of the ETSI Deliverables. References not directly concerned with the implementation/application/understanding of the ETSI Deliverable shall be listed in the Bibliography annex._

_References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies._

_Referenced documents which are not found to be publicly available in the expected location might be found in the [ETSI docbox](https://docbox.etsi.org/Reference/)._

> NOTE:    While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long-term validity.

The following referenced documents are necessary for the application of the present document.

- <a name="_ref_1">[1]</a>    &lt;Standard Organization acronym> &lt;document number> (&lt;version number>): "&lt;Title>".

## 2.2 Informative references

References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.

> NOTE:    While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long-term validity.

The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's understanding but are not required for conformance to the present document.

- <a name="_ref_i.1">[i.1]</a>    Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act).

- <a name="_ref_i.1">[i.2]</a>    NIST SP 800-128 (2011) Guide for Security-Focused Configuration Management of Information Systems

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

# 3 Definition of terms, symbols and abbreviations

## 3.1 Terms

The terms below are important for understanding the purpose and usage of browsers. For the purposes of the present document, the following terms apply:

| Term | Definition |
|------|------------|
| **Access** | The capability to retrieve, load, and display web content from servers through network protocols, including establishing connections, downloading resources, and rendering content for user consumption. |
| **Accessing Web Content** | The complete process by which browsers retrieve, process, and present web resources to end users, encompassing network communication, content parsing, rendering, and user interface presentation. |
| **Browser Extensions** | Software modules that augment browser functionality by adding features, modifying behavior, or enhancing user experience beyond the browser's core capabilities, typically installed and managed through the browser's extension system. |
| **Browsers** | Software products with digital elements that enable end users to access and interact with web content hosted on servers that are connected to local and remote networks. <br><br>*Note: Expert group definition - In the context of this category of products, browsers are software products with digital elements that enable end users to access and interact with web content hosted on servers that are connected to networks such as the Internet.* |
| **Certificate** | A digital document issued by a Certificate Authority that validates the identity of a website and enables encrypted HTTPS connections, verified by browsers through cryptographic signature validation and certificate chain trust evaluation to prevent man-in-the-middle attacks. |
| **Content Security Policy (CSP)** | A browser security mechanism that allows web applications to declare approved sources for executable scripts, styles, and other resources through HTTP headers or meta tags, mitigating cross-site scripting attacks by preventing execution of unauthorized code. |
| **Cross-Site Scripting (XSS)** | A security vulnerability that allows attackers to inject malicious scripts into trusted websites viewed by other users, potentially stealing credentials, session tokens, or sensitive data by executing attacker-controlled code in the victim's browser context. |
| **Custom Protocol** | Non-standard or application-specific communication protocols that browsers may support for specialized content access or functionality, extending beyond traditional web protocols like HTTP/HTTPS. |
| **Embedded Browsers** | Browsers that are intended for integration into another system or application. |
| **End Users** | Natural persons who utilize browsers to access web content for personal, professional, or other purposes, including but not limited to browsing, reading, viewing multimedia content, and interacting with web applications. |
| **Exploit** | A technique, code, or sequence of actions that takes advantage of a vulnerability to achieve unauthorized behavior, such as arbitrary code execution, privilege escalation, sandbox escape, or information disclosure. |
| **Extension API** | Programming interfaces exposed by browsers that enable extensions to access browser functionality, modify web content, intercept network requests, or integrate with browser features, subject to declared permissions and security policies. |
| **Interact** | The critical activity that defines browsing, encompassing user actions such as clicking hyperlinks, submitting forms, executing scripts, manipulating page elements, and engaging with dynamic web content through input devices. |
| **Man-in-the-Middle (MITM) Attack** | An attack where an adversary intercepts and potentially modifies network communication between a browser and server, often exploiting weak encryption, invalid certificates, or unencrypted HTTP connections to eavesdrop on or manipulate data transmission. |
| **Networks** | Communication infrastructures that enable data transmission between browsers and servers, encompassing local area networks (LANs), wide area networks (WANs), and the global Internet. |
| **Origin** | A fundamental security boundary defined by the combination of scheme (protocol), host (domain), and port of a URL, forming the basis for Same-Origin Policy enforcement and determining which web content can access shared resources, storage, and APIs. |
| **Permission** | A user-granted authorization that allows web content to access sensitive browser capabilities or device hardware (camera, microphone, location, notifications, etc.), managed through explicit user consent prompts and revocable through browser settings. |
| **Process Isolation** | The architectural pattern of separating browser components and web content into distinct operating system processes with independent memory spaces and restricted inter-process communication, containing the impact of security vulnerabilities and preventing cross-context data leakage. |
| **Progressive Web Applications** | Web-based applications that operate within the browser environment, leveraging advanced browser APIs and capabilities to provide enhanced functionality including offline operation, background synchronization, push notifications, and device hardware access, while remaining fundamentally dependent on the browser's runtime and security model for execution and user interaction. |
| **Raw Content** | Unprocessed source code and data formats delivered by servers, including but not limited to XML, JSON, JavaScript, HTML, CSS, and other markup or programming languages before browser interpretation. |
| **Renderer Process** | A sandboxed browser process responsible for parsing, executing, and displaying web content including HTML, CSS, and JavaScript, isolated from other content and the browser core to contain potential exploits within a restricted security boundary. |
| **Same-Origin Policy** | The core browser security model that restricts how documents and scripts from one origin can interact with resources from another origin, preventing malicious websites from reading sensitive data or performing unauthorized actions on behalf of users across different web applications. |
| **Sandbox** | An operating system-level security mechanism that restricts the capabilities and system access of browser processes, limiting damage from compromised web content by preventing unauthorized filesystem access, system call execution, or privilege escalation beyond defined boundaries. |
| **Servers** | Computer systems or software applications that store, process, and deliver web content to browsers via network protocols, responding to browser requests with appropriate resources and data. |
| **Standalone Browsers** | Standalone applications that fulfil the functions of browsers. |
| **Telemetry** | Automated collection and transmission of browser usage data, performance metrics, crash reports, and diagnostic information to browser manufacturers for product improvement, typically requiring user consent and subject to privacy controls and data minimization principles. |
| **Vulnerability** | A weakness or flaw in browser implementation that can be exploited by malicious actors to bypass security controls, execute arbitrary code, access unauthorized data, or compromise system integrity, typically addressed through security updates and patches. |
| **Web Content** | The displayed and rendered representation of raw content, transformed by browsers into human-perceivable formats including text, images, videos, interactive elements, and structured layouts as intended by content creators. |
| **WebView** | A platform-specific embedded browser component that enables applications to display web content within their user interface, providing a subset of full browser functionality while operating under the security context and lifecycle of the host application. Common implementations include Android WebView, iOS WKWebView, Windows WebView2, and cross-platform frameworks such as Electron, Tauri, and Chromium Embedded Framework (CEF). |

## 3.2 Symbols

For the purposes of the present document, the [following] symbols [given in ... and the following] apply:

[to be added]

# 4 Product Context

## 4.1 General

## 4.2 Out of scope use/environments

_List uses/environments covered by other legislation or standards (critical, industrial, medical, etc.). Hoping to have a reusable generic list of these soon._

The types of product with digital elements listed in the section do not fall within the scope of the Cyber Resilience Act <a name="_ref_i.1">[i.1]</a>, and are not covered by this standard:

1. Services, except for the remote data processing solutions for a covered product as defined in CRA recitals 11-12; article 3, 2 <a name="_ref_i.1">[i.1]</a>;
2. Products specifically designed or procured for national security and defence purpose as defined in CRA recitals 14 and 26; article 2, 7-8 <a name="_ref_i.1">[i.1]</a>;
3. Products developed for or used exclusively for internal use by public administration as defined in CRA recital 16; article 5, 2 <a name="_ref_i.1">[i.1]</a>;
4. Non-commercial free and open source software as defined in CRA recitals 17-21; article 13, 5 <a name="_ref_i.1">[i.1]</a>;
5. Medical Devices and Software as defined in CRA recital 25; article 2, 2 [a-b] <a name="_ref_i.1">[i.1]</a>;
6. Vehicles, including aviation and marine equipment as defined in CRA recital 27; article 2, 2.c "vehicles"; recital 27; article 2, 3 "aviation"; article 2, 4 "marine equipment" <a name="_ref_i.1">[i.1]</a>;
7. Spare and used parts as defined in CRA recital 29; article 2, 6 <a name="_ref_i.1">[i.1]</a>;
8. Refurbished, repaired, and upgraded products that have not been substantially modifiedas defined in recitals 39 - 42 <a name="_ref_i.1">[i.1]</a>;

The following types of products have reduced or varied requirements under the Cyber Resilience Act <a name="_ref_i.1">[i.1]</a> and can only be partially covered by this standard.

1. High Risk AI as defined in CRA recital 51; article 12 <a name="_ref_i.1">[i.1]</a>;
2. Testing and unfinished versions as defined in recital 37; Article 4, 2-3 <a name="_ref_i.1">[i.1]</a>;
3. Products Placed on the Market Prior to December 11, 2027 as defined in CRA article 69 <a name="_ref_i.1">[i.1]</a>.

## 4.3 In-Scope Components

### 4.3.1 In-Scope components standalone browser

For the purposes of this standard, a standalone browser consists of the following in-scope security-relevant components:

**Core Browser Components**:

1. **Rendering Engine**: HTML parser, CSS engine, layout system, and DOM implementation responsible for processing and displaying web content.

2. **JavaScript Engine**: JavaScript runtime, JIT compiler, garbage collector, and execution context management providing the environment for web application code execution.

3. **Network Stack**: HTTP/HTTPS client implementation, certificate validation, connection management, caching subsystem, and protocol handlers (WebSocket, WebRTC, etc.).

4. **Process Architecture**: Multi-process isolation model including browser process, renderer processes, GPU process, network process, and inter-process communication (IPC) mechanisms.

5. **Storage Subsystem**: Cookie management, localStorage, sessionStorage, IndexedDB, Cache API, origin-partitioned storage, and persistent storage quota management.

6. **Permission System**: Runtime permission prompts, permission state management, permission policy enforcement, and user consent UI for sensitive capabilities (camera, microphone, location, notifications, etc.).

7. **Sandbox Implementation**: Operating system-level process sandboxing, seccomp/AppContainer restrictions, filesystem access controls, and system call filtering.

8. **Security Policy Engines**: Same-Origin Policy enforcement, Cross-Origin Resource Sharing (CORS) validation, Content Security Policy (CSP) parser and enforcer, and Mixed Content blocking.

**Extension System Components** (if present):

9. **Extension Runtime**: Extension process management, manifest validation, permission enforcement for extension APIs, and content script injection mechanism.

10. **Extension API Layer**: Browser APIs exposed to extensions (webRequest, tabs, storage, etc.), permission-based access controls, and extension-to-browser IPC.

**Update and Maintenance Components**:

11. **Update System**: Automatic update mechanism, update signature verification, update rollback capability, and background update process.

12. **Diagnostic and Telemetry**: Crash reporting, error logging, usage metrics collection (where implemented with user consent), and debug logging infrastructure.

**User Interface Components**:

13. **Security Indicators**: HTTPS lock icon, certificate viewer, permission indicators, malicious site warnings, and phishing/malware protection UI.

14. **User Consent UI**: Permission prompts, download confirmations, external protocol handler registration prompts, and security warnings.

**Certificate and Trust Components**:

15. **Certificate Management**: Root certificate store, certificate validation logic, OCSP/CRL checking, Certificate Transparency verification, and certificate pinning.

16. **Trust Decisions**: Safe Browsing integration, malicious site detection, phishing protection, download scanning integration, and security warnings.

**Out-of-Scope Components**:

The following components are explicitly excluded from the security requirements of this standard:

- Third-party websites and web applications accessed through the browser
- Server-side infrastructure operated by the browser manufacturer (sync services, account systems) except where they deliver security-critical updates
- Operating system components and system libraries not distributed as part of the browser package
- Third-party extensions and plugins developed outside the browser manufacturer's control
- User-generated bookmarks, preferences, and configuration data
- Remote attestation or DRM modules that operate under separate security models

### 4.3.2 In-Scope components embedded browser

For the purposes of this standard, an embedded browser (WebView component or integrated browser engine) consists of the following in-scope security-relevant components in addition to or as variations of the standalone browser components listed in [4.3.1](#431-in-scope-components-standalone-browser):

**Embedded Browser Core Components**:

1. **WebView Engine**: The embedded rendering engine (e.g., Android WebView, iOS WKWebView, Electron, CEF, WebView2) including HTML/CSS/JavaScript processing capabilities adapted for host application integration.

2. **Host Application Boundary**: Security boundary enforcement between web content running in the WebView and the native host application code, including context isolation and privilege separation.

3. **JavaScript Bridge**: Native-to-web and web-to-native communication interface allowing controlled interaction between JavaScript running in web content and native application APIs, including message passing and function exposure mechanisms.

4. **Custom URL Scheme Handlers**: Registration and handling of application-specific URL schemes (e.g., app://, custom-protocol://) that trigger native code execution or data retrieval from web content.

5. **WebView Configuration API**: Host application APIs for configuring WebView security properties (JavaScript enablement, file access permissions, content security settings, network access controls).

**Embedded-Specific Security Components**:

6. **Content Source Policy**: Allowlisting and trust management for content sources loaded into the WebView (local files, remote URLs, bundled assets), including validation of content origin and integrity.

7. **Storage Isolation**: Separation of WebView storage (cookies, localStorage, IndexedDB) from both the host application's native storage and from other WebView instances or standalone browsers on the same device.

8. **Permission Delegation**: Mechanism for handling web API permission requests (camera, microphone, location, etc.) where the WebView delegates permission decisions to the host application.

9. **Navigation Controls**: Host application controls over WebView navigation including URL allowlisting, navigation interception, redirect validation, and prevention of unintended navigation to external sites.

10. **Script Injection Controls**: Security mechanisms governing the injection of JavaScript into web content by the host application, including timing, isolation, and privilege level of injected scripts.

**Host Integration Components**:

11. **Native API Exposure Management**: Controlled exposure of native device capabilities (filesystem, camera, sensors, biometrics, secure storage) to web content through the JavaScript bridge with appropriate authorization and validation.

12. **Data Sharing Controls**: Mechanisms for secure data transfer between web content and native application context, including input validation, output encoding, and data sanitization at the boundary.

13. **Event Handling**: WebView event system for navigation events, load events, error events, and security-relevant events (certificate errors, SSL warnings, mixed content detection) with propagation to host application.

14. **Native UI Integration**: Security considerations for WebView rendering within native UI containers, including overlay protection, screenshot prevention for sensitive content, and secure display of trust indicators.

**Update and Maintenance Components** (Embedded-Specific):

15. **WebView Update Mechanism**: System for updating the embedded browser engine independently of the host application (platform-provided WebView updates) or bundled with application updates (Electron, CEF).

16. **Compatibility Validation**: Testing and validation that WebView security properties are maintained across engine updates and remain compatible with host application security requirements.

**Additional Embedded Browser Considerations**:

17. **Process Architecture**: Whether the WebView runs in-process with the host application or in a separate process, and the IPC mechanisms used for communication if separated.

18. **TLS/Certificate Management**: Handling of TLS connections including whether the WebView uses system certificate stores or custom certificate validation, and integration with certificate pinning.

19. **Debugging Interfaces**: Security controls around WebView debugging capabilities (browser developer tools, web inspector interfaces) to prevent unauthorized debugging of production applications.

**Differences from Standalone Browsers**:

Unlike standalone browsers where all web content is considered untrusted, embedded browsers shall:

- Establish selective trust relationships with certain content sources (bundled HTML, local files, specific remote origins) while maintaining security boundaries
- Mediate permissions through the host application rather than direct user prompts
- Share or isolate storage and state management with the host application
- Navigate the security boundary between web content privileges and native application privileges
- Consider the combined attack surface of both the WebView engine and the host application

**Out-of-Scope Components for Embedded Browsers**:

The following components are explicitly excluded from the security requirements for embedded browsers:

- Host application code outside the WebView integration points
- Server-side infrastructure serving content to the WebView (unless operated by the WebView engine provider for security updates)
- Third-party web content loaded into the WebView beyond the control of the host application developer
- Platform WebView implementations provided by the operating system (Android System WebView, iOS WKWebView) where the host application developer has no control over the engine implementation
- Native dependencies and libraries used by the host application but not related to WebView functionality

## 4.4 Use Cases

This clause defines representative use cases that illustrate the diverse operational contexts in which browsers and embedded browser components are deployed. These use cases serve multiple purposes within the conformity assessment framework:

1. **Risk Contextualization**: Each use case is associated with a risk level (Standard, High, or Critical) that reflects the potential impact of security failures in that deployment context, derived from the risk assessment methodology detailed in Annex A.

2. **Requirement Selection Guidance**: The use cases inform the selection of appropriate security capability levels from Chapter 5, helping manufacturers determine which condition levels are suitable for their intended deployment contexts.

3. **Proportionality Principle**: In accordance with the CRA's proportionality principle, these use cases demonstrate how security requirements scale with risk, ensuring that security controls are commensurate with the threats and impacts relevant to each deployment scenario.

4. **Shared Understanding**: The use cases provide a common vocabulary for manufacturers, assessors, and regulators to discuss browser security requirements in relation to real-world deployment contexts.

**Scope and Applicability**:

The use cases defined in this clause encompass both standalone browsers and embedded browser components (WebViews). While the fundamental security capabilities defined in Chapter 5 apply to both categories, the specific threats, deployment environments, and risk profiles differ:

- **Standalone browsers** (UC-B1 through UC-B8) operate as independent applications with direct user interaction and comprehensive security controls managed by the browser itself.

- **Embedded browsers** are represented in UC-B10 and in aspects of other use cases where browser engines are integrated into host applications, requiring consideration of host-web security boundaries and trust relationships.

- **Progressive Web Applications (PWAs)**, while representing an important deployment model, inherit their security properties from the underlying browser (standalone or embedded) in which they execute, and thus are covered by the applicable use case for that browser deployment.

**Use Case Structure**:

Each use case provides:

- **Description**: The primary purpose and scope of the deployment
- **Typical workflows**: Common user interactions and usage patterns
- **Typical environments**: Physical and network contexts in which the browser operates
- **Security considerations**: Key threats, vulnerabilities, and security controls relevant to the use case
- **Risk level**: Overall risk classification (Standard, High, or Critical)
- **Rationale**: Justification for the assigned risk level based on threat landscape and potential impact

**Risk Levels Explained**:

- **Standard Risk**: General-purpose deployments where security failures primarily affect individual users, with limited financial or societal impact. Standard security capabilities are appropriate.

- **High Risk**: Deployments involving sensitive personal data, financial transactions, health information, organizational data, or authenticated access to critical services. Enhanced security capabilities and stricter condition levels are recommended.

- **Critical Risk**: Deployments where security failures could result in significant physical harm, disruption of essential services, compromise of critical infrastructure, or large-scale societal impact. Maximum security capabilities with the strictest condition levels are required.

## 4.4.1 Application to Conformity Assessment

Manufacturers shall use these use cases as follows:

1. **Identify Applicable Use Cases**: Determine which use case(s) best represent the intended purpose and deployment context of the browser or embedded browser component.

2. **Assess Risk Level**: Evaluate whether the assigned risk level (Standard, High, Critical) aligns with the manufacturer's risk assessment for their specific deployment. Where multiple use cases apply, the highest applicable risk level should be considered.

3. **Select Security Capabilities**: Use Annex B to identify the recommended security capability condition levels for the applicable use case(s). These recommendations represent typical configurations; manufacturers may select stricter conditions based on their risk assessment or specific deployment requirements.

4. **Document Rationale**: In conformity assessment documentation, manufacturers should clearly identify which use case(s) apply to their product and provide justification for any deviations from recommended capability levels.

5. **Consider Use Case Combinations**: Many deployments will span multiple use cases (e.g., a browser used for both general web browsing and enterprise applications). In such cases, manufacturers should satisfy requirements for all applicable use cases or implement use-case-specific profiles.

**Note**: These use cases are representative and not exhaustive. Manufacturers deploying browsers in contexts not explicitly covered by these use cases should conduct a detailed risk assessment per Annex A and select security capability levels appropriate to the identified risks.

## 4.4.2 Use Cases for Browsers

UC-B1: General Purpose Web Browsing

- Description: Browsing of public websites for news, social media, entertainment, shopping, streaming, and general information. Excludes authenticated access to sensitive personal or organizational systems.
- Typical workflows: High tab count with frequent context switching; passive consumption (reading/watching); form fills; long idle sessions.
- Typical environments: Personal devices used in homes, cafes, transit, or public spaces. No physical security controls; high exposure to shoulder surfing, untrusted networks, or device theft.
- Security considerations: Tracking protection; HTTPS-only mode; blocking of malicious sites; access to camera/microphone/location; exposure to browser extensions; integrated password management; profile separation.
- Risk level: Standard
- Rationale: Primary threats originate from web content (malware, trackers, phishing) rather than targeted compromise.

UC-B2: Development and Testing Environments

- Description: Browser usage by developers, QA, and testers for building, debugging, and validating web applications, including compatibility testing with pre-release (canary/nightly/beta) browser builds.
- Typical workflows: Frequent navigation to localhost/internal IPs; manual and automated interaction with untrusted or malformed code; usage of developer tools; HAR/network capture; testing auth flows.
- Typical environments: Developer workstations in office or home offices; may be BYOD or corporate-managed; moderate physical security.
- Security considerations: Isolation using ephemeral profiles or web browser private mode, allowlists for extensions, supply chain auditing, curation and anonymization of test data.
- Risk level: High
- Rationale: Exposure to untrusted code, experimental browser features, and misconfiguration increases likelihood of exploit execution or leakage of credentials.

UC-B3: Kiosks and Shared Terminals

- Description: Multi-user public or semi-public devices for check-in, customer service, library access, clinic intake, or retail assistance.
- Typical workflows: Short, single-purpose sessions (check-in, lookup, form submission); no authentication or credential entry.
- Typical environments: Fixed-location terminals in lobbies, libraries, clinics, classrooms or stores.
- Security considerations: Strict domain allowlist; no access to camera/mic/location/notifications; block credential saving and autofill; remote wipe and health monitoring; encryption of cached assets.
- Risk level: High
- Rationale: High turnover of untrusted users combined with potential for physical tampering.

UC-B4: Financial Services Access

- Description: Access to online banking, brokerage, payments, crypto exchanges, wallets, and insurance portals involving monetary transactions or sensitive financial data.
- Typical workflows: Daily logins; balance checks; initiating transfers/payments; uploading documents.
- Typical environments: Primarily personal devices in uncontrolled locations; corporate devices in secure facilities
- Security considerations: HTTPS-only mode; credential monitoring for breaches.
- Risk level: High
- Rationale: Exposure to financial fraud and account takeover; session hijacking; MITM;

UC-B5: Healthcare and Medical Systems

- Description: Browser access to EHRs, telemedicine platforms, patient portals, prescription systems or health insurance.
- Typical workflows: Patient record access/modification; remote consultations; e-prescribing; uploading/downloading diagnostic files.
- Typical environments: #TODO: Similar to home + hospital workstations?
- Security considerations: Session re-auth for sensitive actions, auto-timeout after inactivity, data encryption at rest/in transit.
- Risk level: High
- Rationale: Regulatory penalties, reputational damage, and potential patient safety risks.

UC-B6: E-Government Services Access

- Description: Access to citizen-facing or administrative government portals for taxes, benefits, licenses, identity verification, legal filings, or voting systems.
- Typical workflows: Infrequent but critical sessions, form filling, document uploads, digital signature application.
- Typical environments: #TODO: Personal devices or public terminals.
- Security considerations: Strong authentication; digital signature validation; certificate management.
- Risk level: High
- Rationale: Compromise can lead to identity theft, benefit fraud, election interference, or erosion of civic trust.

UC-B7: Enterprise Applications

- Description: Internal browser-based tools for CRM, ERP, HRMS, document collaboration, project management and BI,
- Typical workflows: Daily CRUD operations of records, document management, 
- Typical environments: Corporate laptops, desktops, or BYOD devices used remotely or on-premise.
- Security considerations: SSO, DLP (control copy/paste/print/download actions), allowlist for extensions, integration with SIEM, containerization of BYOD.
- Risk level: High
- Rationale: Exposure of intellectual property, customer data, or internal operations to exfiltration or insider threat.

UC-B8: Critical Infrastructure

- Description: Web interfaces for SCADA, energy grid, water treatment, transportation control, or emergency dispatch.
- Typical workflows: Administered access, scoped to individual user accounts.
- Typical environments: Secure control rooms, data centers, or field stations - physically access-controlled, often air-gapped or operating within segmented network.
- Security considerations: Certificate management; zero trust architecture; mTLS; RBAC; supply chain controls; immutable logging.
- Risk level: Critical
- Rationale: Successful attack could disrupt essential services, cause physical damage, or endanger human life.

UC-B9: Security Research #TODO: Perhaps this one is too much

- Description: Intentional browsing to analyze phishing pages, malware or malicious extensions.
- Typical workflows: Automated or manual navigation to malicious URLs; downloading/executing payloads in sandbox; DOM inspection; screenshot/HAR capture; behavioral logging.
- Typical environments: Dedicated lab machines or air-gapped workstations, often behind shielded network zones.
- Security considerations: Isolation using disposable VMs, capture of all artifacts and network traffic;
- Risk level: Critical
- Rationale: Deliberate exposure to live threats; failure can lead to host compromise, lateral movement, or data exfiltration.

UC-B10: Adapted Browser with Modified Features

- Description: A manufacturer creates a product based on an existing open-source browser (e.g., Chromium, Firefox) by adding custom features, modifying default configurations, integrating proprietary services, or tailoring the browser for specific market segments, enterprise deployments, or regional requirements.
- Typical workflows: Standard web browsing workflows similar to general-purpose browsers, but with manufacturer-specific features such as custom home pages, integrated search providers, proprietary sync services, enhanced privacy controls, vertical-specific toolbars, or pre-configured extension bundles.
- Typical environments: All environments applicable to the underlying browser engine (personal devices, corporate workstations, mobile devices, kiosks), but with manufacturer-controlled default configurations and update channels.
- Security considerations: Inheritance of upstream browser vulnerabilities; security review of added features and modifications; validation that customizations do not weaken existing security controls; secure management of manufacturer-operated services (sync, accounts, analytics); timely integration of upstream security patches; transparency regarding data collection by added features; supply chain security for bundled extensions or services; verification that modifications maintain sandboxing and isolation properties; compliance with baseline browser security requirements while accounting for manufacturer additions.
- Risk level: Standard to High (depends on extent of modifications and deployment context)
- Rationale: The security posture depends on both the upstream browser's security and the manufacturer's implementation quality. Added features introduce additional attack surface and potential vulnerabilities. Delayed or incomplete integration of upstream patches can extend exposure to known vulnerabilities. Manufacturer-operated services create additional trust dependencies and data processing considerations. However, when properly implemented, adapted browsers can maintain equivalent security to their upstream base while providing differentiated user value. The risk level increases when modifications are extensive, when manufacturer services handle sensitive data, or when the browser is deployed in high-risk contexts (UC-B4 through UC-B8).


## 4.5 Product overview and architecture

## 4.5.1 Product Definition

A standalone browser is a software application that enables users to access, retrieve, and interact with content on the World Wide Web and other network resources. Unlike embedded browsers or WebView components integrated into other applications, standalone browsers operate as independent applications with direct user interfaces, comprehensive feature sets, and autonomous update mechanisms.

## 4.5.2 Architectural Overview

### 4.5.2.1 Core Architecture Components

The browser architecture consists of several interconnected subsystems:

**Rendering Engine**: Processes HTML, CSS, and JavaScript to display web content. This includes the DOM parser, CSS engine, and layout system that transforms web resources into visual representations.

**JavaScript Engine**: Executes JavaScript code in isolated contexts, providing the runtime environment for dynamic web applications while maintaining security boundaries between different execution contexts.

**Network Stack**: Manages all network communications including HTTP/HTTPS requests, WebSocket connections, and other protocols. Implements connection pooling, caching, and security features such as certificate validation.

**Process Architecture**: Modern browsers employ multi-process architectures where the main browser process is separated from renderer processes, plugin processes, and GPU processes. This isolation prevents compromise of one process from affecting others.

**Storage Subsystem**: Manages various forms of local data storage including cookies, localStorage, IndexedDB, and cache storage, each with distinct security properties and access controls.

### 4.5.2.2 Security Architecture

**Sandbox Model**: Web content executes within restricted sandboxes that limit access to system resources. The sandbox is enforced at multiple levels - process isolation at the OS level, and API restrictions at the browser level.

**Permission System**: Browsers mediate access to sensitive capabilities (camera, microphone, location, notifications) through a permission system that requires explicit user consent and provides ongoing usage indicators.

**Content Security Boundaries**: The Same-Origin Policy (SOP) forms the fundamental security boundary, ensuring that content from one origin cannot access resources from another origin without explicit permission.

**Certificate and Trust Management**: Browsers maintain root certificate stores and implement certificate validation, including mechanisms for certificate pinning, HSTS (HTTP Strict Transport Security), and Certificate Transparency.

### 4.5.2.3 Extension Architecture

Browser extensions operate in a unique position within the security model:

- **Privileged Execution Context**: Extensions run with elevated privileges compared to web content, able to intercept and modify network requests, access cross-origin resources, and interact with browser APIs.

- **Manifest-Based Permissions**: Extensions declare required permissions in manifests, which are presented to users during installation. However, the granularity and understandability of these permissions remain challenges.

- **Content Script Injection**: Extensions can inject scripts into web pages, creating a three-way trust relationship between the browser, the extension, and the web content.

## 4.5.3 Trust Boundaries and Threat Model

### 4.5.3.1 Trust Zones

1. **Browser Core** (Highest Trust): The browser executable and core libraries, typically signed and verified by the operating system.

2. **Browser Extensions** (Elevated Trust): Third-party code with significant privileges, operating between web content and browser core.

3. **Web Applications** (Limited Trust): JavaScript applications running within the browser sandbox with restricted capabilities.

4. **Web Content** (Untrusted): General web content including advertisements, user-generated content, and third-party resources.

5. **Network** (Untrusted): All network communications are considered potentially hostile, requiring encryption and validation.

### 4.5.3.2 Attack Surface

The browser presents multiple attack surfaces:

- **Network Interface**: Exposed to malicious servers, man-in-the-middle attacks, and protocol-level exploits
- **Rendering Engine**: Subject to parsing vulnerabilities, memory corruption, and logic bugs
- **JavaScript Engine**: Target for JIT compiler bugs, type confusion, and sandbox escapes
- **Extension APIs**: Abused by malicious extensions or compromised legitimate extensions
- **User Interface**: Social engineering through spoofing, phishing, and permission fatigue
- **Local Storage**: Cross-site tracking, data exfiltration, and persistence mechanisms

## 4.5.4 Deployment Contexts

### 4.5.4.1 Consumer Environment

Individual users installing browsers on personal devices, typically with:

- Direct internet connectivity
- Mixed personal and professional usage
- User-managed security decisions
- Varied technical expertise levels

### 4.5.4.2 Enterprise Environment

Organizational deployments requiring:

- Centralized policy management
- Compliance with regulatory requirements
- Integration with security infrastructure (proxies, SIEM systems)
- Controlled update cycles
- Restriction of certain features or extensions

### 4.5.4.3 Specialized Environments

- **Kiosk Mode**: Public-facing browsers with locked-down configurations
- **Development Mode**: Browsers with relaxed security for testing
- **Privacy-Focused**: Configurations emphasizing anonymity and tracking prevention
- **Isolated Browsing**: Air-gapped or heavily restricted network access

## 4.5.5 Security-Relevant Characteristics

### 4.5.5.1 Dynamic Threat Landscape

Browsers face constantly evolving threats as new web standards introduce new capabilities, zero-day vulnerabilities are discovered, and attack techniques advance. The browser serves as the primary interface between users and potentially hostile internet content.

### 4.5.5.2 Compatibility Requirements

Browsers shall maintain backward compatibility with legacy web content while implementing new security features, creating tension between security and functionality. This includes supporting older TLS versions, maintaining compatibility with enterprise applications, and handling non-standard web content. Should the usage of legacy web content impact the security of the browser, then the content shall be ignored.

### 4.5.5.3 Performance Constraints

Security measures shall be balanced against performance requirements. Users expect instantaneous page loads and smooth interactions, limiting the computational overhead available for security checks. This affects decisions around sandboxing granularity, encryption methods, and validation procedures.

### 4.5.5.4 User Agency and Autonomy

Unlike many security products, browsers shall respect user choice while protecting against threats. Users may choose to:

- Visit dangerous websites despite warnings
- Install risky extensions
- Disable security features for compatibility
- Share sensitive information voluntarily

This requirement for user agency fundamentally shapes the browser security model, requiring informed consent mechanisms rather than purely restrictive controls.

## 4.6 Essential functions

The essential functions of a browser, as defined for the purposes of this standard, are those capabilities that shall remain operational to fulfill the browser's primary purpose of enabling secure access to web content and services. These functions form the baseline against which security requirements are assessed.

This section addresses both **standalone browsers** (independent applications with direct user interfaces) and **embedded browsers** (browser engines integrated into host applications, commonly referred to as WebViews, browser components, or embedded web rendering engines).

### 4.6.1 Core Essential Functions

**Content Retrieval and Rendering**: The browser shall retrieve web resources via network protocols (primarily HTTP/HTTPS) and render them into a visual and interactive presentation for the user. This includes:

- HTML parsing and DOM construction
- CSS styling and layout computation
- JavaScript and WebAssembly execution within secure sandboxes
- Rendering of images, media, and other embedded content

*For embedded browsers*: The host application may provide additional constraints on content sources, implement content filtering, or restrict certain rendering features. However, the fundamental capability to securely parse and render web content remains essential. See reference: [WebView Security Best Practices](https://owasp.org/www-community/controls/Securing_WebView).

**Navigation and Session Management**: The browser shall enable navigation between web resources and maintain session state including navigation history and form data.

*For standalone browsers*: This includes managing multiple concurrent browsing contexts (tabs, windows) with independent session states.

*For embedded browsers*: Navigation may be constrained by the host application to approved domains or URL patterns. The host application is responsible for implementing navigation controls and may delegate or restrict back/forward navigation. Session management may be simplified or controlled by the host application. See reference: [Android WebView Security](https://developer.android.com/develop/ui/views/layout/webapps/webview#safe-browsing).

**Cryptographic Communication**: The browser shall establish encrypted connections to web servers using TLS/SSL protocols (TLS 1.2 minimum, TLS 1.3 recommended), validate server certificates, and provide indicators of connection security status.

*For standalone browsers*: Visual security indicators (padlock icons, address bar coloring) shall be prominently displayed in the user interface.

*For embedded browsers*: Security indicators may be delegated to the host application's UI. The host application shall be responsible for surfacing certificate validation status to end users when handling sensitive data. Certificate pinning may be implemented at the host application level. See references: [Certificate Pinning](https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning), [TLS Best Practices](https://wiki.mozilla.org/Security/Server_Side_TLS).

**Data Storage**: The browser shall provide controlled mechanisms for web applications to store data locally, including cookies, localStorage, IndexedDB, and cache storage, subject to security policies and user controls.

*For embedded browsers*: Storage isolation from the host application is critical. The embedded browser shall maintain separate storage contexts that are not directly accessible to host application code without explicit bridging. Storage may be partitioned per embedded browser instance to prevent data leakage between different uses within the same application. See reference: [WebView Data Isolation](https://source.android.com/docs/security/features/webview).

**User Input and Interaction**: The browser shall accept and process user inputs (keyboard, mouse, touch) and deliver them securely to web content, while protecting against input injection attacks and unauthorized access to input devices.

*For embedded browsers*: Input handling shall prevent the host application from injecting synthetic events that could bypass user consent (e.g., programmatically triggering clicks on permission prompts). The boundary between host-provided input and user-generated input shall be clearly maintained. See reference: [Input Validation in WebViews](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html).

### 4.6.2 Security-Related Essential Functions

**Isolation and Sandboxing**: The browser shall maintain security boundaries between different origins, processes, and execution contexts to prevent unauthorized access and limit the impact of compromised content.

*For embedded browsers*: A critical additional boundary exists between the embedded browser content and the host application. This boundary shall prevent:

- Web content from accessing host application memory, files, or system resources without explicit bridging
- Web content from executing arbitrary code in the host application context
- Host application code from arbitrarily accessing or manipulating web content internal state

The host application shall implement a secure bridge or message-passing interface for controlled communication between web content and native code. See references: [WebView Isolation](https://source.chromium.org/chromium/chromium/src/+/main:docs/webview_isolation.md), [iOS WKWebView Security](https://developer.apple.com/documentation/webkit/wkwebview).

**Permission Management**: The browser shall mediate access to sensitive capabilities (camera, microphone, location, notifications, clipboard) through a permission system that requires user consent and provides ongoing visibility.

*For embedded browsers*: Permission requests may be delegated to the host application, which is then responsible for obtaining appropriate user consent and respecting platform-level permission grants. The host application shall not automatically grant permissions to embedded web content without user awareness. Permissions granted to the host application shall not automatically extend to all web content loaded in embedded browsers. See reference: [WebView Permissions Model](https://developer.android.com/reference/android/webkit/WebChromeClient#onPermissionRequest(android.webkit.PermissionRequest)).

**Update Mechanism**: The browser shall maintain the capability to receive, verify, and apply security updates to address vulnerabilities and maintain security effectiveness over the product lifecycle.

*For standalone browsers*: Direct update mechanisms with user notification and control.

*For embedded browsers*: Updates are typically delivered as part of operating system updates (for system WebViews) or application updates (for bundled browser engines). The host application developer is responsible for:

- Using up-to-date versions of embedded browser components
- Monitoring security advisories for the embedded browser engine
- Deploying application updates that include patched browser components
- Not pinning to outdated versions of browser engines with known vulnerabilities

See references: [Android System WebView Updates](https://developer.android.com/about/versions/nougat/android-7.0#webview), [Electron Security Updates](https://www.electronjs.org/docs/latest/tutorial/security).

**Certificate Validation**: The browser shall validate server certificates against trusted root certificate authorities and enforce certificate transparency requirements to detect mis-issued certificates.

*For embedded browsers*: Certificate validation shall use the platform's trusted certificate store unless explicit certificate pinning is implemented by the host application. The host application shall not disable certificate validation except in clearly documented development/testing scenarios that are disabled in production builds. See reference: [Certificate Validation Best Practices](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html).

### 4.6.3 Embedded Browser-Specific Security Functions

**JavaScript Bridge Security**: For embedded browsers that expose native functionality to web content through JavaScript bridges (e.g., `addJavascriptInterface` in Android WebView, `WKScriptMessageHandler` in iOS), the following are essential:

- **Input Validation**: All data passed from web content to native code shall be validated and sanitized to prevent injection attacks
- **Output Encoding**: Data passed from native code to web content shall be properly encoded to prevent XSS
- **Minimal Exposed Surface**: Only necessary functionality shall be exposed; avoid exposing powerful or sensitive APIs
- **Authentication**: Bridge calls that perform sensitive operations shall verify origin and intent
- **Intent Validation**: For URL schemes and intent handlers, validate and sanitize all parameters

See references: [Android WebView JavaScript Interface Security](https://developer.android.com/develop/ui/views/layout/webapps/webview#addjavascriptinterface), [iOS JavaScript Bridge Security](https://developer.apple.com/documentation/webkit/wkscriptmessagehandler).

**Content Source Validation**: Embedded browsers shall validate and restrict content sources:

- **Allowlist Enforcement**: Maintain allowlists of approved domains/URLs when loading sensitive functionality
- **Local Content Handling**: When loading local HTML/JS resources, ensure they cannot be overwritten or manipulated by untrusted code
- **Deep Link Validation**: Validate and sanitize deep links that cause content to load in embedded browsers

See reference: [Mobile Application Security Testing Guide - WebViews](https://mas.owasp.org/MASTG/tests/).

**Host Application Data Exposure Prevention**: The embedded browser shall prevent web content from accessing host application data through:

- **File System Isolation**: Preventing JavaScript file:// access to arbitrary application files
- **Database Isolation**: Preventing web content from accessing native application databases
- **Shared Preferences/User Defaults Isolation**: Protecting native application settings from web access
- **Intent/URL Scheme Filtering**: Validating and restricting URL scheme invocations that could manipulate the host application

See reference: [OWASP Mobile Security Testing Guide](https://owasp.org/www-project-mobile-security-testing-guide/).

### 4.6.4 Functions NOT Considered Essential

The following functions, while commonly present in browsers, are not considered essential for the core purpose and may be disabled or restricted in high-security configurations without fundamentally impairing browser functionality:

**For standalone browsers**:

- Extension/add-on support
- Synchronization of browsing data across devices
- Built-in password management
- Autofill of forms
- Access to hardware devices beyond display and basic input
- Developer tools and debugging interfaces (except in designated development builds)
- Support for legacy protocols or deprecated web standards
- Integration with external applications or services beyond standard web APIs

**For embedded browsers** (in addition to the above):

- Multiple tab/window management (may be simplified to single content view)
- Browser history UI (may be delegated to host application)
- Download management UI (host application typically handles downloads)
- Print functionality (host application may provide)
- Find-in-page functionality (host application may provide)
- Reader mode or content simplification features

## 4.7 Operational Environment

The operational environment encompasses the technical, physical, and organizational contexts in which browsers are deployed and operated. Understanding these environments is essential for appropriate security configuration and risk assessment.

### 4.7.1 Technical Environment

**Platform Diversity**: Browsers operate across heterogeneous platforms including:

- Desktop operating systems (Windows, macOS, Linux)
- Mobile operating systems (iOS, Android)
- Embedded systems and IoT devices
- Virtualized and containerized environments

Each platform provides different security primitives (process isolation, memory protection, file system controls) that browsers leverage for security enforcement.

**Network Conditions**: Browsers shall operate across varying network environments:

- Trusted corporate networks with security controls and monitoring
- Home networks with varying security configurations
- Public Wi-Fi networks with potential adversarial presence
- Mobile networks with carrier-level controls
- Air-gapped or isolated networks in high-security environments

Network conditions directly impact threat exposure, with untrusted networks requiring enhanced protection against network-level attacks (MITM, eavesdropping, traffic manipulation).

**Hardware Capabilities**: The operational environment includes diverse hardware with varying security features:

- Devices with Trusted Platform Modules (TPM) or secure enclaves
- Systems with hardware-enforced memory protection (DEP, ASLR)
- Devices with biometric authentication capabilities
- Systems with varying performance characteristics affecting security feature feasibility

### 4.7.2 Physical Environment

**Physical Security Controls**: Browser deployment contexts vary significantly in physical security:

- **Controlled Environments**: Corporate offices, data centers, and secure facilities with physical access controls, surveillance, and authorized personnel only
- **Semi-Controlled Environments**: Home offices, shared workspaces with moderate physical security
- **Uncontrolled Environments**: Public spaces, cafes, transit where device theft, shoulder surfing, and physical tampering are realistic threats
- **Hostile Environments**: Border crossings, adversarial jurisdictions where targeted physical attacks or device seizure may occur

**Device Ownership and Control**:

- **Corporate-Owned Devices**: Centrally managed with enforced policies, monitoring, and remote management capabilities
- **Bring Your Own Device (BYOD)**: Personal devices used for work purposes with limited organizational control
- **Shared Devices**: Multi-user systems (kiosks, family computers) where isolation between users is required
- **Personal Devices**: Individually owned and managed with user-determined security configurations

### 4.7.3 Organizational Environment

**Governance and Compliance**: Organizations deploying browsers may be subject to: