EN-304-617_v0.0.6.md

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).

UC-B11: Desktop Applications with Embedded Browser Navigation

- Description: Software applications built with frameworks like Electron, Tauri, or similar technologies that provide browser-like navigation capabilities, allowing users to navigate to user-defined URLs while maintaining an application-like experience. These applications typically combine web technologies with native capabilities and may provide custom UI chrome, integrated features, and controlled navigation within a defined scope.
- Typical workflows: User-initiated navigation to URLs (bookmarked, typed, or linked); form filling and authentication; downloading files; viewing multimedia content; interaction with web APIs (camera, location, notifications) as permitted by the application; switching between multiple views or tabs managed by the application.
- Typical environments: Desktop workstations (Windows, macOS, Linux) in home offices, corporate environments, or educational settings; installed as native applications with filesystem access; may integrate with system services and native APIs.
- Security considerations: Host-web boundary enforcement; JavaScript bridge security; custom protocol handler validation; URL allowlisting/blocklisting; content security policy enforcement; prevention of navigation to untrusted domains; isolation between web content and native functionality; secure handling of file:// URLs and local resources; protection against XSS and injection attacks targeting the native bridge; update mechanism security for both native and web components.
- Risk level: High
- Rationale: These applications combine the attack surface of both web browsers and native applications. Navigation to user-defined URLs introduces exposure to arbitrary web content while the native integration creates additional vectors for privilege escalation. The JavaScript bridge between web and native contexts is particularly sensitive as it can expose native APIs to potentially malicious web content. Vulnerabilities can lead to local file access, credential theft, or system compromise. The risk is elevated compared to standard web browsing due to the trusted native context and potential for broader system access.

UC-B12: Super-App Platforms

- Description: A super-app is a software platform that hosts and supports other applications (mini-apps), enabling their execution by using the platform's resources. Super-apps function as the hosting environment where multiple mini-apps execute, providing unified discovery (app stores, QR codes, search), shared authentication, resource management, and content curation. Examples include platforms like Alipay, Baidu, WeChat, and similar multi-service aggregation platforms.
- Typical workflows: Mini-app discovery and launch via in-app stores, QR codes, or search; shared authentication across hosted mini-apps; payment processing and financial transactions; access to platform-provided APIs (camera, location, contacts, payment systems); switching between multiple active mini-apps; integration with platform-level services (messaging, social features, notifications).
- Typical environments: Mobile devices (iOS, Android) and desktop applications; multi-user context with shared platform identity; high-frequency daily usage; integration with financial services, social networks, and e-commerce systems; operation in diverse network conditions including public WiFi and cellular networks.
- Security considerations: Mini-app isolation and sandboxing; validation and review of mini-apps before hosting; platform API access control and permissions; shared authentication security across mini-apps; payment and financial transaction security; data sharing boundaries between mini-apps and platform; prevention of malicious mini-apps compromising the platform or other mini-apps; supply chain security for third-party mini-apps; session management across multiple mini-apps; protection of platform-level credentials and tokens; monitoring and logging of mini-app behavior; enforcement of content security policies per mini-app; secure communication channels between mini-apps and platform services.
- Risk level: High
- Rationale: Super-apps aggregate significant user trust and typically handle sensitive operations including financial transactions, personal data access, and authentication credentials used across multiple services. The multi-tenant nature creates complex isolation requirements where compromise of one mini-app should not affect others or the platform itself. The platform's API surface exposed to mini-apps creates potential for privilege escalation or unauthorized data access. Financial integration, combined with the broad scope of functionality and third-party mini-app ecosystem, creates elevated risk for fraud, data breach, and platform-wide compromise. The aggregation of multiple services increases the potential impact of security failures.


## 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:

- Regulatory requirements (GDPR, EU Data Act, sector-specific regulations)
- Industry standards and certification requirements
- Internal security policies and acceptable use policies
- Contractual obligations to customers or partners

**Security Maturity**: Organizations vary in security capabilities:

- **Advanced**: Dedicated security teams, SIEM integration, threat intelligence, security orchestration
- **Intermediate**: Basic security tools, patch management, logging and monitoring
- **Basic**: Default configurations, reactive security posture, limited security resources

**User Training and Awareness**: The effectiveness of browser security controls depends on user security awareness:

- Ability to recognize phishing attempts and malicious websites
- Understanding of permission prompts and security indicators
- Adherence to security policies and best practices
- Reporting of security incidents

### 4.7.4 Threat Environment

The operational environment includes varying threat actor capabilities and motivations:

**Opportunistic Threats**: Automated attacks, commodity malware, and broad-spectrum phishing affecting general internet users

**Targeted Threats**: Attacks directed at specific organizations, industries, or individuals including:

- Corporate espionage and intellectual property theft
- Financial fraud and account takeover
- Nation-state surveillance and intelligence gathering
- Ransomware and extortion campaigns

**Insider Threats**: Risks from authorized users with legitimate access who may act maliciously or negligently

**Supply Chain Threats**: Compromise of browser components, extensions, or integrated services during development, distribution, or update processes

### 4.7.5 Lifecycle Environment

**Development and Testing**: Browsers used in development environments encounter untrusted code, pre-release features, and non-standard configurations that increase risk exposure.

**Production Deployment**: Operational browsers serving end-users with expected availability, performance, and security requirements.

**Decommissioning**: End-of-life browsers that may still contain sensitive data requiring secure disposal or migration processes.

**Update and Maintenance**: Browsers require ongoing updates that shall be delivered securely, tested for stability, and deployed without service interruption.

## 4.8 Users

Browser users encompass a diverse population with varying technical expertise, security awareness, and usage patterns. Understanding user characteristics is essential for designing effective security controls that users can understand and properly utilize.

### 4.8.1 User Categories

**General Consumers**: The largest user population, including:

- Minimal to moderate technical expertise
- Primary activities: web browsing, social media, shopping, entertainment, personal email
- Security awareness varies widely; may not recognize threats
- Expect seamless user experience; security friction reduces adoption
- Limited ability to troubleshoot security issues independently

**Professional Users**: Individuals using browsers for work-related activities:

- Moderate technical expertise with domain-specific knowledge
- Activities: SaaS applications, web-based productivity tools, professional research
- Subject to organizational security policies
- Generally higher security awareness due to training
- Balance productivity needs with security requirements

**Developers and Technical Users**: Advanced users with deep technical knowledge:

- High technical expertise; understand browser internals and web standards
- Activities: web development, testing, debugging, performance analysis
- Require access to developer tools and advanced features
- Higher tolerance for security friction; may disable controls intentionally
- Capable of understanding and responding to complex security warnings

**Enterprise Administrators**: IT personnel managing browser deployments:

- High technical expertise in systems administration
- Responsible for configuring, deploying, and managing browsers at scale
- Implement group policies and security configurations
- Monitor browser usage and security events
- Balance security requirements with user productivity

**Children and Protected Users**: Vulnerable populations requiring enhanced protection:

- Limited technical expertise and security awareness
- Susceptible to social engineering and inappropriate content
- Require parental controls and content filtering
- May not understand consequences of security decisions
- Need simplified security interfaces with reduced decision-making burden

### 4.8.2 User Behavior Patterns

**Security Decision-Making**: Users exhibit common patterns in security decisions:

- **Alert Fatigue**: Repeated security prompts lead to automatic dismissal without reading
- **Optimism Bias**: Underestimation of personal risk ("it won't happen to me")
- **Immediate Gratification**: Preference for immediate access over security delay
- **Trust Misplacement**: Difficulty distinguishing legitimate from malicious content
- **Habituation**: Security behaviors become routine without conscious evaluation

**Permission Granting**: When presented with permission requests, users typically:

- Grant permissions to accomplish immediate tasks without evaluating necessity
- Lack understanding of implications of granted permissions
- Rarely review or revoke previously granted permissions
- May not notice when permissions are being actively used

**Update Behavior**: User approaches to browser updates vary:

- Some users apply updates immediately when prompted
- Others defer updates indefinitely to avoid interruption
- Many users unaware of update status or importance
- Corporate environments often enforce centralized update management

### 4.8.3 User Needs and Expectations

**Usability**: Users expect browsers to be:

- Intuitive and easy to use without extensive training
- Responsive and fast, with minimal performance impact from security features
- Compatible with their required websites and applications
- Consistent across sessions and devices

**Privacy**: Users increasingly expect:

- Control over personal data collection and usage
- Protection from tracking by advertisers and third parties
- Transparency about data practices
- Compliance with privacy regulations

**Security**: While security awareness varies, users generally expect:

- Protection from malware and phishing without constant manual intervention
- Clear warnings when accessing dangerous sites
- Secure handling of passwords and payment information
- Prevention of unauthorized access to sensitive data

**Transparency**: Users need:

- Understandable explanations of security features and warnings
- Visibility into what data is being collected and shared
- Clear indication of security status (encrypted connections, permissions in use)
- Accessible security settings and controls

### 4.8.4 User Assistance and Responsibilities

**User Responsibilities**: Effective browser security requires users to:

- Keep browsers updated to address vulnerabilities
- Exercise caution with extension installation
- Recognize and avoid phishing attempts
- Use strong, unique passwords for web accounts
- Respond appropriately to security warnings
- Report security incidents when encountered

**Browser Responsibilities to Users**: Browsers shall support users by:

- Providing clear, actionable security warnings
- Using understandable language avoiding technical jargon
- Offering contextual help and explanations
- Defaulting to secure configurations
- Making security controls discoverable and accessible
- Minimizing security decision burden through sound defaults

### 4.8.5 Accessibility Considerations

Security features shall be accessible to users with disabilities:

- **Visual Impairments**: Security indicators shall be perceivable by screen readers; warnings shall not rely solely on color
- **Cognitive Disabilities**: Security messages shall be simple and clear; complex security decisions should be minimized
- **Motor Impairments**: Security controls shall be operable with alternative input methods
- **Hearing Impairments**: Audio-based security notifications shall have visual alternatives

Accessibility requirements shall not compromise security effectiveness, but security features should not exclude users with disabilities from safe browser usage.

# 5 Browser-Specific Risk Factors

### 5.1 Isolation Mechanisms

#### 5.1.1 Domain and Origin Isolation

**[DOM]** The manufacturer shall ensure that execution contexts belonging to different origins are securely isolated to prevent unauthorized data access, code execution, or state manipulation across boundaries.
Isolation shall include process separation, independent storage and cache spaces, and validation of all cross-origin communication through standardized, browser-mediated mechanisms such as Cross-Origin Resource Sharing (CORS), which allows controlled sharing of resources between origins through validated HTTP headers, and postMessage, which provides a secure message-passing interface between isolated contexts (e.g. frames or windows).
Any relaxation of isolation shall be explicitly authorized, documented, and monitored to prevent data leakage or privilege escalation.

**Capability**: Browser enforces isolation between domains and origins (defined by scheme, host, and port) to protect integrity and confidentiality of data and execution.

**Conditions**:

* DOM-0: Full isolation: Each origin is strictly separated. No mechanism exists for cross-origin access or relaxation.
* DOM-1: Controlled isolation: Isolation is enforced by default but may be selectively relaxed through standardized, browser-mediated mechanisms (e.g. CORS or postMessage) with explicit validation.
* DOM-2: Configurable isolation: Isolation is enforced by default, but users or administrators can define exceptions via explicit configuration or policy.
* DOM-3: Integrated isolation: Isolation remains in place, but third-party integrations, compatibility modes, or embedded components may introduce controlled exceptions under defined policies.

**Threats**:

- Cross-site scripting (XSS) attacks
- Cross-site request forgery (CSRF)
- Data exfiltration between origins
- Session hijacking
- Clickjacking

**Risk**: HIGH - Failure of isolation mechanisms enables immediate compromise of user data across multiple web applications

**Requirements**:

#### DOM-0 Requirements (Full isolation)

- **DOM-0-REQ-1**: Browser shall implement process-per-site isolation for all origins → Assessment: DOM-REQ-1
- **DOM-0-REQ-2**: Browser shall enforce Cross-Origin Read Blocking (CORB) for all cross-origin resource loads → Assessment: DOM-REQ-2
- **DOM-0-REQ-3**: Browser shall prevent all cross-origin DOM access without exception → Assessment: DOM-REQ-3
- **DOM-0-REQ-4**: Browser shall isolate localStorage and IndexedDB per origin with no sharing mechanism → Assessment: DOM-REQ-6
- **DOM-0-REQ-5**: Browser shall treat all sandboxed and data: origins as opaque with no relaxation → Assessment: DOM-REQ-8
- **DOM-0-REQ-6**: Browser shall enforce document.domain restrictions without any override mechanism → Assessment: DOM-REQ-12

#### DOM-1 Requirements (Controlled isolation)

- **DOM-1-REQ-1**: Browser shall implement process-per-site isolation → Assessment: DOM-REQ-1
- **DOM-1-REQ-2**: Browser shall enforce CORB with exceptions only for properly configured CORS headers → Assessment: DOM-REQ-2
- **DOM-1-REQ-3**: Browser shall prevent cross-origin DOM access except via postMessage → Assessment: DOM-REQ-3
- **DOM-1-REQ-4**: Browser shall enforce CORS preflight for all non-simple cross-origin requests → Assessment: DOM-REQ-4
- **DOM-1-REQ-5**: Browser shall enforce SameSite cookie attribute with Lax as default → Assessment: DOM-REQ-5
- **DOM-1-REQ-6**: Browser shall isolate storage per origin → Assessment: DOM-REQ-6
- **DOM-1-REQ-7**: Browser shall support iframe sandbox attribute with granular tokens → Assessment: DOM-REQ-7
- **DOM-1-REQ-8**: Browser shall treat sandboxed and data: origins as opaque → Assessment: DOM-REQ-8
- **DOM-1-REQ-9**: Browser shall restrict document.domain setter by default (require Origin-Agent-Cluster opt-out) → Assessment: DOM-REQ-12

#### DOM-2 Requirements (Configurable isolation)

- **DOM-2-REQ-1**: Browser shall implement process-per-site isolation → Assessment: DOM-REQ-1
- **DOM-2-REQ-2**: Browser shall enforce CORB → Assessment: DOM-REQ-2
- **DOM-2-REQ-3**: Browser shall prevent cross-origin DOM access except via CORS and postMessage → Assessment: DOM-REQ-3
- **DOM-2-REQ-4**: Browser shall enforce CORS preflight → Assessment: DOM-REQ-4
- **DOM-2-REQ-5**: Browser shall enforce SameSite cookie policies → Assessment: DOM-REQ-5
- **DOM-2-REQ-6**: Browser shall isolate storage per origin → Assessment: DOM-REQ-6
- **DOM-2-REQ-7**: Browser shall support iframe sandboxing → Assessment: DOM-REQ-7
- **DOM-2-REQ-8**: Browser shall support Cross-Origin-Resource-Policy (CORP) header → Assessment: DOM-REQ-9
- **DOM-2-REQ-9**: Browser shall enforce Cross-Origin-Opener-Policy (COOP) → Assessment: DOM-REQ-10
- **DOM-2-REQ-10**: Browser shall enforce Cross-Origin-Embedder-Policy (COEP) → Assessment: DOM-REQ-11
- **DOM-2-REQ-11**: Administrators shall be able to configure origin isolation policies via enterprise policy → Assessment: DOM-REQ-13
- **DOM-2-REQ-12**: Browser shall log all policy-based isolation exceptions → Assessment: DOM-REQ-14

#### DOM-3 Requirements (Integrated isolation)

- **DOM-3-REQ-1**: Browser shall implement baseline process-per-site isolation → Assessment: DOM-REQ-1
- **DOM-3-REQ-2**: Browser shall enforce CORB with documented exceptions for compatibility → Assessment: DOM-REQ-2
- **DOM-3-REQ-3**: Browser shall enforce CORS policies → Assessment: DOM-REQ-4
- **DOM-3-REQ-4**: Browser shall enforce SameSite cookie policies → Assessment: DOM-REQ-5
- **DOM-3-REQ-5**: Browser shall isolate storage per origin → Assessment: DOM-REQ-6
- **DOM-3-REQ-6**: Browser shall support CORP, COOP, and COEP headers → Assessments: DOM-REQ-9, DOM-REQ-10, DOM-REQ-11
- **DOM-3-REQ-7**: Compatibility modes shall not weaken core isolation boundaries → Assessment: DOM-REQ-15
- **DOM-3-REQ-8**: Third-party integrations shall be subject to same origin isolation policies → Assessment: DOM-REQ-16
- **DOM-3-REQ-9**: All isolation exceptions for compatibility shall be documented and logged → Assessment: DOM-REQ-17
- **DOM-3-REQ-10**: Embedded components shall maintain storage isolation from embedding context → Assessment: DOM-REQ-18

### 5.2 Extension System Security

#### 5.2.1 Third-Party Code Execution

**[EXT]** The manufacturer shall implement controls for third-party extensions that can modify browser behavior, considering that certified extensions may still exhibit malicious behavior.

**Capability**: Browser extension system with APIs for third-party code augmentation

**Conditions**:

- EXT-0: No extension support
- EXT-1: Curated extension store only
- EXT-2: Curated store with developer mode
- EXT-3: Unrestricted extension installation

**Threats**:

- Malicious extensions harvesting user data
- Extension-based cryptomining
- Browser fingerprinting
- Privilege escalation through extension APIs
- Supply chain attacks on popular extensions

**Risk**: HIGH - Extensions operate as semi-trusted code with significant access to browser functionality and user data

**Requirements**:

#### EXT-0 Requirements (No extension support)

- **EXT-0-REQ-1**: Browser shall not provide any extension installation or execution capability → Assessment: EXT-REQ-19
- **EXT-0-REQ-2**: Browser shall block all attempts to load extension code → Assessment: EXT-REQ-20
- **EXT-0-REQ-3**: Browser build shall not include extension subsystem components → Assessment: EXT-REQ-21

#### EXT-1 Requirements (Curated extension store only)

- **EXT-1-REQ-1**: Browser shall implement granular permission model for extensions → Assessment: EXT-REQ-1
- **EXT-1-REQ-2**: Browser shall isolate extension content scripts from page scripts → Assessment: EXT-REQ-2
- **EXT-1-REQ-3**: Browser shall enforce extension API access control based on declared permissions → Assessment: EXT-REQ-3
- **EXT-1-REQ-4**: Browser shall validate extension manifests before installation → Assessment: EXT-REQ-4
- **EXT-1-REQ-5**: Browser shall sandbox extension execution environments → Assessment: EXT-REQ-5
- **EXT-1-REQ-6**: Browser shall isolate extensions from each other → Assessment: EXT-REQ-6
- **EXT-1-REQ-7**: Browser shall validate host permissions against declared patterns → Assessment: EXT-REQ-7
- **EXT-1-REQ-8**: Browser shall enforce Content Security Policy for extensions → Assessment: EXT-REQ-8
- **EXT-1-REQ-9**: Browser shall verify extension update signatures from official store → Assessment: EXT-REQ-10
- **EXT-1-REQ-10**: Browser shall enforce Manifest V3 compliance for new extensions → Assessment: EXT-REQ-13
- **EXT-1-REQ-11**: Browser shall validate extension signatures before installation → Assessment: EXT-REQ-17
- **EXT-1-REQ-12**: Browser shall provide transparent permissions UI during installation → Assessment: EXT-REQ-18
- **EXT-1-REQ-13**: Browser shall only allow installation from official curated store → Assessment: EXT-REQ-22
- **EXT-1-REQ-14**: Extensions shall undergo security review before store publication → Assessment: EXT-REQ-23

#### EXT-2 Requirements (Curated store with developer mode)

- **EXT-2-REQ-1**: Browser shall implement all EXT-1 requirements for store-installed extensions
- **EXT-2-REQ-2**: Browser shall isolate extension storage per extension → Assessment: EXT-REQ-11
- **EXT-2-REQ-3**: Browser shall restrict background script capabilities → Assessment: EXT-REQ-12
- **EXT-2-REQ-4**: Browser shall enforce WebRequest API security controls → Assessment: EXT-REQ-9
- **EXT-2-REQ-5**: Browser shall monitor extension-controlled web content → Assessment: EXT-REQ-15
- **EXT-2-REQ-6**: Developer mode shall require explicit user activation with security warnings → Assessment: EXT-REQ-24
- **EXT-2-REQ-7**: Developer mode extensions shall display persistent visual indicators → Assessment: EXT-REQ-25
- **EXT-2-REQ-8**: Developer mode shall disable automatic extension updates → Assessment: EXT-REQ-26
- **EXT-2-REQ-9**: Browser shall log all developer mode extension activities → Assessment: EXT-REQ-27
- **EXT-2-REQ-10**: Enterprise policies shall be able to disable developer mode → Assessment: EXT-REQ-28

#### EXT-3 Requirements (Unrestricted extension installation)

- **EXT-3-REQ-1**: Browser shall implement baseline extension permission model → Assessment: EXT-REQ-1
- **EXT-3-REQ-2**: Browser shall enforce content script isolation → Assessment: EXT-REQ-2
- **EXT-3-REQ-3**: Browser shall control extension API access → Assessment: EXT-REQ-3
- **EXT-3-REQ-4**: Browser shall validate extension manifests → Assessment: EXT-REQ-4
- **EXT-3-REQ-5**: Browser shall sandbox extensions → Assessment: EXT-REQ-5
- **EXT-3-REQ-6**: Browser shall isolate extensions from each other → Assessment: EXT-REQ-6
- **EXT-3-REQ-7**: Browser shall enforce native messaging security controls → Assessment: EXT-REQ-14
- **EXT-3-REQ-8**: Browser shall monitor extension telemetry with privacy protections → Assessment: EXT-REQ-16
- **EXT-3-REQ-9**: Sideloaded extensions shall display prominent security warnings → Assessment: EXT-REQ-29
- **EXT-3-REQ-10**: Browser shall provide user controls to review and revoke extension permissions → Assessment: EXT-REQ-30
- **EXT-3-REQ-11**: Browser shall scan sideloaded extensions for known malware signatures → Assessment: EXT-REQ-31
- **EXT-3-REQ-12**: All extension security events shall be logged for review → Assessment: EXT-REQ-32

### 5.3 Encryption Implementation

#### 5.3.1 Data Protection Layers

**[ENC]** The manufacturer shall implement comprehensive encryption across all data states and communication channels.

**Capability**: Multi-layer encryption for data in transit, at rest, and during synchronization

**Conditions**:

- ENC-0: Full encryption with hardware security module support
- ENC-1: Standard encryption with software-based key management
- ENC-2: Selective encryption based on data sensitivity
- ENC-3: Basic encryption with user-optional enhanced protection
- ENC-4: Minimal encryption

**Threats**:

- Man-in-the-middle attacks
- Data breach of stored credentials
- Synchronization data interception
- Update channel compromise
- Certificate validation bypass

**Risk**: CRITICAL - Encryption failures expose all user data and communications

**Requirements**:

#### ENC-0 Requirements (Full encryption with HSM support)

- **ENC-0-REQ-1**: Browser shall support TLS 1.3 or higher exclusively for all network communications → Assessment: ENC-REQ-1
- **ENC-0-REQ-2**: Browser shall perform complete certificate chain validation including expiry, revocation, and trust anchor verification → Assessment: ENC-REQ-2
- **ENC-0-REQ-3**: Browser shall enforce HTTP Public Key Pinning (HPKP) or alternative certificate pinning mechanisms → Assessment: ENC-REQ-3
- **ENC-0-REQ-4**: Browser shall enforce HTTP Strict Transport Security (HSTS) with preload support → Assessment: ENC-REQ-4
- **ENC-0-REQ-5**: Browser shall block all mixed content without exception → Assessment: ENC-REQ-5
- **ENC-0-REQ-6**: Browser shall enforce Certificate Transparency requirements for all certificates → Assessment: ENC-REQ-6
- **ENC-0-REQ-7**: Browser shall support and validate OCSP stapling responses → Assessment: ENC-REQ-7
- **ENC-0-REQ-8**: Browser shall restrict cipher suites to strong, modern algorithms only → Assessment: ENC-REQ-8
- **ENC-0-REQ-9**: Browser shall enforce perfect forward secrecy for all TLS connections → Assessment: ENC-REQ-9
- **ENC-0-REQ-10**: Browser shall perform real-time certificate revocation checking → Assessment: ENC-REQ-10
- **ENC-0-REQ-11**: Browser shall implement Web Crypto API with full W3C compliance → Assessment: ENC-REQ-11
- **ENC-0-REQ-12**: Browser shall provide cryptographically secure random number generation → Assessment: ENC-REQ-12
- **ENC-0-REQ-13**: Browser shall enforce SubResource Integrity (SRI) validation → Assessment: ENC-REQ-13
- **ENC-0-REQ-14**: Browser shall support Encrypted SNI (ESNI) or Encrypted Client Hello (ECH) → Assessment: ENC-REQ-14
- **ENC-0-REQ-15**: Browser shall display prominent, non-bypassable certificate error UI → Assessment: ENC-REQ-15
- **ENC-0-REQ-16**: Browser shall operate in HTTPS-first mode with automatic upgrade → Assessment: ENC-REQ-16
- **ENC-0-REQ-17**: Browser shall detect and alert on certificate pinning bypass attempts → Assessment: ENC-REQ-17
- **ENC-0-REQ-18**: Browser shall protect against TLS downgrade attacks → Assessment: ENC-REQ-18
- **ENC-0-REQ-19**: Browser shall deprecate and disable legacy cryptographic protocols (SSL, TLS 1.0/1.1) → Assessment: ENC-REQ-19
- **ENC-0-REQ-20**: Browser shall isolate cryptographic keys in hardware security modules when available → Assessment: ENC-REQ-20
- **ENC-0-REQ-21**: Browser shall implement secure certificate store with integrity protection → Assessment: ENC-REQ-21
- **ENC-0-REQ-22**: Browser shall not allow user override of certificate pinning failures → Assessment: ENC-REQ-22
- **ENC-0-REQ-23**: All cryptographic operations shall be performed in hardware-backed secure enclaves when available → Assessment: ENC-REQ-23

#### ENC-1 Requirements (Standard encryption with software key management)

- **ENC-1-REQ-1**: Browser shall support TLS 1.3 or higher for all network communications → Assessment: ENC-REQ-1
- **ENC-1-REQ-2**: Browser shall perform complete certificate chain validation → Assessment: ENC-REQ-2
- **ENC-1-REQ-3**: Browser shall support certificate pinning mechanisms → Assessment: ENC-REQ-3
- **ENC-1-REQ-4**: Browser shall enforce HSTS to prevent protocol downgrade attacks → Assessment: ENC-REQ-4
- **ENC-1-REQ-5**: Browser shall block mixed content with opt-in for passive content → Assessment: ENC-REQ-5
- **ENC-1-REQ-6**: Browser shall validate Certificate Transparency logs → Assessment: ENC-REQ-6
- **ENC-1-REQ-7**: Browser shall support OCSP stapling → Assessment: ENC-REQ-7
- **ENC-1-REQ-8**: Browser shall restrict cipher suites to industry-standard secure algorithms → Assessment: ENC-REQ-8
- **ENC-1-REQ-9**: Browser shall prefer perfect forward secrecy cipher suites → Assessment: ENC-REQ-9
- **ENC-1-REQ-10**: Browser shall perform certificate revocation checking (OCSP or CRLSets) → Assessment: ENC-REQ-10
- **ENC-1-REQ-11**: Browser shall implement Web Crypto API → Assessment: ENC-REQ-11
- **ENC-1-REQ-12**: Browser shall provide secure random number generation → Assessment: ENC-REQ-12
- **ENC-1-REQ-13**: Browser shall support SubResource Integrity validation → Assessment: ENC-REQ-13
- **ENC-1-REQ-14**: Browser shall display clear certificate error UI with bypass warnings → Assessment: ENC-REQ-15
- **ENC-1-REQ-15**: Browser shall support HTTPS-first mode as user option → Assessment: ENC-REQ-16
- **ENC-1-REQ-16**: Browser shall protect against TLS downgrade attacks → Assessment: ENC-REQ-18
- **ENC-1-REQ-17**: Browser shall disable legacy cryptographic protocols by default → Assessment: ENC-REQ-19
- **ENC-1-REQ-18**: Browser shall isolate cryptographic keys in process-level sandboxes → Assessment: ENC-REQ-20
- **ENC-1-REQ-19**: Browser shall implement secure certificate store → Assessment: ENC-REQ-21

#### ENC-2 Requirements (Selective encryption)

- **ENC-2-REQ-1**: Browser shall support TLS 1.3 and TLS 1.2 → Assessment: ENC-REQ-1
- **ENC-2-REQ-2**: Browser shall perform certificate chain validation → Assessment: ENC-REQ-2
- **ENC-2-REQ-3**: Browser shall support certificate pinning for critical domains → Assessment: ENC-REQ-3
- **ENC-2-REQ-4**: Browser shall enforce HSTS when declared by server → Assessment: ENC-REQ-4
- **ENC-2-REQ-5**: Browser shall warn about mixed content → Assessment: ENC-REQ-5
- **ENC-2-REQ-6**: Browser shall support Certificate Transparency → Assessment: ENC-REQ-6
- **ENC-2-REQ-7**: Browser shall support OCSP stapling → Assessment: ENC-REQ-7
- **ENC-2-REQ-8**: Browser shall support standard cipher suites → Assessment: ENC-REQ-8
- **ENC-2-REQ-9**: Browser shall support forward secrecy cipher suites → Assessment: ENC-REQ-9
- **ENC-2-REQ-10**: Browser shall perform revocation checking with soft-fail option → Assessment: ENC-REQ-10
- **ENC-2-REQ-11**: Browser shall implement Web Crypto API → Assessment: ENC-REQ-11
- **ENC-2-REQ-12**: Browser shall provide secure random number generation → Assessment: ENC-REQ-12
- **ENC-2-REQ-13**: Browser shall support SubResource Integrity → Assessment: ENC-REQ-13
- **ENC-2-REQ-14**: Browser shall display certificate errors with bypass option → Assessment: ENC-REQ-15
- **ENC-2-REQ-15**: Browser shall provide HTTPS upgrade suggestions → Assessment: ENC-REQ-16
- **ENC-2-REQ-16**: Browser shall maintain secure certificate store → Assessment: ENC-REQ-21
- **ENC-2-REQ-17**: Users shall be able to configure encryption strictness levels → Assessment: ENC-REQ-24
- **ENC-2-REQ-18**: Browser shall provide visual indicators for connection security status → Assessment: ENC-REQ-25

#### ENC-3 Requirements (Basic encryption with optional enhanced protection)

- **ENC-3-REQ-1**: Browser shall support TLS 1.2 or higher → Assessment: ENC-REQ-1
- **ENC-3-REQ-2**: Browser shall perform basic certificate validation → Assessment: ENC-REQ-2
- **ENC-3-REQ-3**: Browser shall enforce HSTS when enabled → Assessment: ENC-REQ-4
- **ENC-3-REQ-4**: Browser shall notify users of mixed content → Assessment: ENC-REQ-5
- **ENC-3-REQ-5**: Browser shall support common cipher suites → Assessment: ENC-REQ-8
- **ENC-3-REQ-6**: Browser shall support certificate revocation checking → Assessment: ENC-REQ-10
- **ENC-3-REQ-7**: Browser shall implement Web Crypto API → Assessment: ENC-REQ-11
- **ENC-3-REQ-8**: Browser shall provide secure random number generation → Assessment: ENC-REQ-12
- **ENC-3-REQ-9**: Browser shall display certificate errors with clear bypass options → Assessment: ENC-REQ-15
- **ENC-3-REQ-10**: Browser shall support basic certificate store operations → Assessment: ENC-REQ-21
- **ENC-3-REQ-11**: Users shall have full control over encryption settings → Assessment: ENC-REQ-26
- **ENC-3-REQ-12**: Browser shall provide encryption status indicators in UI → Assessment: ENC-REQ-27
- **ENC-3-REQ-13**: Legacy protocol support may be enabled for compatibility with user consent → Assessment: ENC-REQ-28

#### ENC-4 Requirements (Minimal encryption)

- **ENC-4-REQ-1**: Browser shall support TLS 1.2 → Assessment: ENC-REQ-1
- **ENC-4-REQ-2**: Browser shall perform basic certificate validation → Assessment: ENC-REQ-2
- **ENC-4-REQ-3**: Browser shall display certificate warnings → Assessment: ENC-REQ-15
- **ENC-4-REQ-4**: Browser shall implement Web Crypto API for web applications → Assessment: ENC-REQ-11
- **ENC-4-REQ-5**: Browser shall provide secure random number generation → Assessment: ENC-REQ-12
- **ENC-4-REQ-6**: Users shall have complete control over all encryption policies → Assessment: ENC-REQ-29
- **ENC-4-REQ-7**: Browser shall support legacy protocols when explicitly enabled by user → Assessment: ENC-REQ-30

### 5.4 Diagnostic and Monitoring Systems

#### 5.4.1 Logging and Crash Reporting

**[LOG]** The manufacturer shall balance diagnostic capabilities with privacy protection in logging and monitoring systems.

**Capability**: Crash dumps, audit trails, activity logs, and enterprise integration capabilities

**Conditions**:

- LOG-0: No logging or local-only logging
- LOG-1: Opt-in telemetry with anonymization
- LOG-2: Default telemetry with opt-out