EN-304-617_v0.0.4.md

- **UPD-1-REQ-4**: Browser shall validate update manifest integrity → Assessment: UPD-REQ-4
- **UPD-1-REQ-5**: Browser shall implement rollback protection → Assessment: UPD-REQ-5
- **UPD-1-REQ-6**: Browser shall isolate update channels → Assessment: UPD-REQ-6
- **UPD-1-REQ-7**: Browser shall support component updates → Assessment: UPD-REQ-7
- **UPD-1-REQ-8**: Browser shall support emergency updates → Assessment: UPD-REQ-8
- **UPD-1-REQ-9**: Browser shall verify updates before installation → Assessment: UPD-REQ-9
- **UPD-1-REQ-10**: Browser shall implement update failure recovery → Assessment: UPD-REQ-10
- **UPD-1-REQ-11**: Browser shall log updates to transparency log → Assessment: UPD-REQ-11
- **UPD-1-REQ-12**: Browser shall secure delta updates → Assessment: UPD-REQ-12
- **UPD-1-REQ-13**: Browser shall authenticate update servers → Assessment: UPD-REQ-13
- **UPD-1-REQ-14**: Browser shall implement update timing jitter → Assessment: UPD-REQ-14
- **UPD-1-REQ-15**: Browser shall enforce background updates → Assessment: UPD-REQ-15
- **UPD-1-REQ-16**: Browser shall display clear update notifications → Assessment: UPD-REQ-16
- **UPD-1-REQ-17**: Browser shall force critical updates with limited postponement → Assessment: UPD-REQ-17
- **UPD-1-REQ-18**: Browser shall verify update verification chain → Assessment: UPD-REQ-18
- **UPD-1-REQ-19**: Browser shall implement update source pinning → Assessment: UPD-REQ-19
- **UPD-1-REQ-20**: Browser shall verify update integrity → Assessment: UPD-REQ-20
- **UPD-1-REQ-21**: Browser shall support staged rollouts → Assessment: UPD-REQ-21
- **UPD-1-REQ-22**: Browser shall validate update domains → Assessment: UPD-REQ-22
- **UPD-1-REQ-23**: Users shall be able to postpone non-critical updates for limited time (max 7 days) → Assessment: UPD-REQ-26
- **UPD-1-REQ-24**: Critical security updates shall not be postponable beyond 24 hours → Assessment: UPD-REQ-27
- **UPD-1-REQ-25**: Browser shall notify users of pending updates with severity indication → Assessment: UPD-REQ-28

#### UPD-2 Requirements (Optional automatic updates)

- **UPD-2-REQ-1**: Browser shall support automatic update mechanism when enabled → Assessment: UPD-REQ-1
- **UPD-2-REQ-2**: Browser shall verify update signatures → Assessment: UPD-REQ-2
- **UPD-2-REQ-3**: Browser shall deliver updates over HTTPS → Assessment: UPD-REQ-3
- **UPD-2-REQ-4**: Browser shall validate update manifest integrity → Assessment: UPD-REQ-4
- **UPD-2-REQ-5**: Browser shall implement rollback protection → Assessment: UPD-REQ-5
- **UPD-2-REQ-6**: Browser shall isolate update channels → Assessment: UPD-REQ-6
- **UPD-2-REQ-7**: Browser shall support component updates → Assessment: UPD-REQ-7
- **UPD-2-REQ-8**: Browser shall verify updates before installation → Assessment: UPD-REQ-9
- **UPD-2-REQ-9**: Browser shall implement update failure recovery → Assessment: UPD-REQ-10
- **UPD-2-REQ-10**: Browser shall authenticate update servers → Assessment: UPD-REQ-13
- **UPD-2-REQ-11**: Browser shall display update notifications → Assessment: UPD-REQ-16
- **UPD-2-REQ-12**: Browser shall verify update integrity → Assessment: UPD-REQ-20
- **UPD-2-REQ-13**: Browser shall validate update domains → Assessment: UPD-REQ-22
- **UPD-2-REQ-14**: Automatic updates shall be disabled by default → Assessment: UPD-REQ-29
- **UPD-2-REQ-15**: Browser shall prominently recommend enabling automatic updates → Assessment: UPD-REQ-30
- **UPD-2-REQ-16**: Browser shall display security warnings when updates are available → Assessment: UPD-REQ-31
- **UPD-2-REQ-17**: Browser shall provide easy mechanism to check for and install updates → Assessment: UPD-REQ-32
- **UPD-2-REQ-18**: Users shall have full control over update timing and installation → Assessment: UPD-REQ-33

#### UPD-3 Requirements (Manual updates only)

- **UPD-3-REQ-1**: Browser shall verify update signatures when manually triggered → Assessment: UPD-REQ-2
- **UPD-3-REQ-2**: Browser shall deliver updates over HTTPS → Assessment: UPD-REQ-3
- **UPD-3-REQ-3**: Browser shall validate update manifest integrity → Assessment: UPD-REQ-4
- **UPD-3-REQ-4**: Browser shall implement rollback protection → Assessment: UPD-REQ-5
- **UPD-3-REQ-5**: Browser shall verify updates before installation → Assessment: UPD-REQ-9
- **UPD-3-REQ-6**: Browser shall implement update failure recovery → Assessment: UPD-REQ-10
- **UPD-3-REQ-7**: Browser shall authenticate update servers → Assessment: UPD-REQ-13
- **UPD-3-REQ-8**: Browser shall display update availability notifications → Assessment: UPD-REQ-16
- **UPD-3-REQ-9**: Browser shall verify update integrity → Assessment: UPD-REQ-20
- **UPD-3-REQ-10**: Browser shall validate update domains → Assessment: UPD-REQ-22
- **UPD-3-REQ-11**: Browser shall provide manual update check mechanism → Assessment: UPD-REQ-34
- **UPD-3-REQ-12**: Browser shall display security warnings for outdated versions → Assessment: UPD-REQ-35
- **UPD-3-REQ-13**: Browser shall provide clear indication of available security updates → Assessment: UPD-REQ-36
- **UPD-3-REQ-14**: All updates shall require explicit user initiation → Assessment: UPD-REQ-37
- **UPD-3-REQ-15**: Browser shall display update changelog and security impact → Assessment: UPD-REQ-38

### 5.6 Protocol Handler Security

#### 5.6.1 Custom Protocol Management

**[PRO]** The manufacturer shall securely handle various communication protocols beyond standard HTTP/HTTPS.

**Capability**: Support for custom schemes, WebSocket, WebRTC, and emerging web standards

**Conditions**:

- PRO-0: HTTP/HTTPS only
- PRO-1: Standard web protocols with strict validation
- PRO-2: Custom protocols with registration system
- PRO-3: Unrestricted protocol handler registration

**Threats**:

- Protocol confusion attacks
- Scheme hijacking
- Bypass of security controls via custom protocols
- Data leakage through protocol handlers
- Local application exploitation via URL schemes

**Risk**: MEDIUM - Custom protocols can bypass standard web security controls

**Requirements**:

#### PRO-0 Requirements (HTTP/HTTPS only)

- **PRO-0-REQ-1**: Browser shall only support HTTP and HTTPS protocols → Assessment: PRO-REQ-24
- **PRO-0-REQ-2**: Browser shall reject all custom protocol handler registration attempts → Assessment: PRO-REQ-25
- **PRO-0-REQ-3**: Browser shall block access to non-standard URL schemes (file://, data://, javascript://, etc.) → Assessment: PRO-REQ-26
- **PRO-0-REQ-4**: Browser shall not provide registerProtocolHandler() API or equivalent functionality → Assessment: PRO-REQ-27
- **PRO-0-REQ-5**: Browser shall reject navigation to any non-HTTP/HTTPS protocols → Assessment: PRO-REQ-28

#### PRO-1 Requirements (Standard web protocols with strict validation)

- **PRO-1-REQ-1**: Browser shall validate all custom protocol handler registrations → Assessment: PRO-REQ-1
- **PRO-1-REQ-2**: Browser shall obtain explicit user consent before activating custom protocol handlers → Assessment: PRO-REQ-2
- **PRO-1-REQ-3**: Browser shall enforce protocol allowlists that restrict which custom schemes can be registered → Assessment: PRO-REQ-3
- **PRO-1-REQ-4**: Browser shall prevent scheme hijacking attacks → Assessment: PRO-REQ-4
- **PRO-1-REQ-5**: Browser shall sanitize protocol URL parameters before passing to handlers → Assessment: PRO-REQ-5
- **PRO-1-REQ-6**: Browser shall implement security controls for external protocol handlers → Assessment: PRO-REQ-6
- **PRO-1-REQ-7**: Browser shall provide transparent UI indicating protocol handler registration and invocation → Assessment: PRO-REQ-7
- **PRO-1-REQ-8**: Browser shall prevent protocol downgrade attacks → Assessment: PRO-REQ-8
- **PRO-1-REQ-9**: Browser shall log protocol handler registration, modification, and invocation events → Assessment: PRO-REQ-9
- **PRO-1-REQ-10**: Browser shall support web+custom scheme conventions → Assessment: PRO-REQ-10
- **PRO-1-REQ-11**: Browser shall enforce handler capability restrictions → Assessment: PRO-REQ-13
- **PRO-1-REQ-12**: Browser shall provide protocol handler revocation mechanisms → Assessment: PRO-REQ-14
- **PRO-1-REQ-13**: Browser shall enforce cross-origin protocol restrictions → Assessment: PRO-REQ-15

#### PRO-2 Requirements (Custom protocols with registration system)

- **PRO-2-REQ-1**: Browser shall implement all PRO-1 requirements
- **PRO-2-REQ-2**: Browser shall validate protocol handler persistence across sessions → Assessment: PRO-REQ-11
- **PRO-2-REQ-3**: Browser shall mitigate protocol confusion attacks → Assessment: PRO-REQ-12
- **PRO-2-REQ-4**: Browser shall validate protocol handler manifests → Assessment: PRO-REQ-16
- **PRO-2-REQ-5**: Browser shall integrate protocol handlers with Content Security Policy → Assessment: PRO-REQ-20
- **PRO-2-REQ-6**: Browser shall maintain audit trail for handler registrations → Assessment: PRO-REQ-21
- **PRO-2-REQ-7**: Browser shall enforce secure handler update mechanisms → Assessment: PRO-REQ-22
- **PRO-2-REQ-8**: Browser shall enforce handler isolation between origins → Assessment: PRO-REQ-23
- **PRO-2-REQ-9**: Browser shall support Intent URL security on Android platforms → Assessment: PRO-REQ-17
- **PRO-2-REQ-10**: Browser shall support Universal Links security on iOS platforms → Assessment: PRO-REQ-18
- **PRO-2-REQ-11**: Browser shall validate mobile deep linking security → Assessment: PRO-REQ-19
- **PRO-2-REQ-12**: Enterprise administrators shall be able to configure protocol handler allowlists and blocklists → Assessment: PRO-REQ-29

#### PRO-3 Requirements (Unrestricted protocol registration)

- **PRO-3-REQ-1**: Browser shall implement baseline protocol handler validation → Assessment: PRO-REQ-1
- **PRO-3-REQ-2**: Browser shall obtain user consent for protocol handler activation → Assessment: PRO-REQ-2
- **PRO-3-REQ-3**: Browser shall sanitize protocol parameters → Assessment: PRO-REQ-5
- **PRO-3-REQ-4**: Browser shall implement external handler security controls → Assessment: PRO-REQ-6
- **PRO-3-REQ-5**: Browser shall provide handler management UI → Assessment: PRO-REQ-7
- **PRO-3-REQ-6**: Browser shall log protocol handler security events → Assessment: PRO-REQ-9
- **PRO-3-REQ-7**: Browser shall allow registration of custom schemes without web+ prefix → Assessment: PRO-REQ-30
- **PRO-3-REQ-8**: Browser shall display security warnings for non-standard protocol handlers → Assessment: PRO-REQ-31
- **PRO-3-REQ-9**: Browser shall provide user-accessible handler revocation controls → Assessment: PRO-REQ-14
- **PRO-3-REQ-10**: Users shall be able to review all registered protocol handlers in browser settings → Assessment: PRO-REQ-32
- **PRO-3-REQ-11**: Browser shall scan custom handlers for known security vulnerabilities → Assessment: PRO-REQ-33
- **PRO-3-REQ-12**: All protocol handler security exceptions shall be logged and auditable → Assessment: PRO-REQ-34

### 5.7 Core Component Security

#### 5.7.1 System Resource Access

**[SYS]** The manufacturer shall implement secure boundaries between web content and system resources through Hardware Abstraction Layers and API mediation.

**Capability**: HAL implementation, PWA support, accessibility features, and local storage mechanisms

**Conditions**:

- SYS-0: Fully sandboxed with no system access
- SYS-1: Limited system access with strict permissions
- SYS-2: Extended system access for PWAs
- SYS-3: Native-equivalent system access

**Threats**:

- Sandbox escape attacks
- Unauthorized file system access
- Hardware fingerprinting
- Resource exhaustion attacks
- Accessibility feature abuse for screen reading

**Risk**: CRITICAL - System access breaches can compromise the entire host environment

**Requirements**:

#### SYS-0 Requirements (Fully sandboxed, no system access)

- **SYS-0-REQ-1**: Browser shall enforce process-level sandboxing for all web content → Assessment: SYS-REQ-1
- **SYS-0-REQ-2**: Browser shall isolate renderer processes from each other and browser core → Assessment: SYS-REQ-2
- **SYS-0-REQ-3**: Browser shall isolate GPU rendering in separate sandboxed process → Assessment: SYS-REQ-3
- **SYS-0-REQ-4**: Browser shall isolate network operations in separate process or service → Assessment: SYS-REQ-4
- **SYS-0-REQ-5**: Browser shall block all filesystem access from web content → Assessment: SYS-REQ-5
- **SYS-0-REQ-6**: Browser shall block all device API access (no camera, microphone, location, etc.)
- **SYS-0-REQ-7**: Browser shall enforce strict hardware resource limits → Assessment: SYS-REQ-20
- **SYS-0-REQ-8**: Browser shall enforce memory isolation between processes → Assessment: SYS-REQ-21
- **SYS-0-REQ-9**: Browser shall implement sandbox escape prevention mechanisms → Assessment: SYS-REQ-26
- **SYS-0-REQ-10**: Browser shall implement Spectre/Meltdown mitigations → Assessment: SYS-REQ-27
- **SYS-0-REQ-11**: Browser shall implement side-channel attack mitigations → Assessment: SYS-REQ-28
- **SYS-0-REQ-12**: Browser shall not expose any native messaging interfaces
- **SYS-0-REQ-13**: Browser shall block all host OS integration features

#### SYS-1 Requirements (Limited system access with strict permissions)

- **SYS-1-REQ-1**: Browser shall enforce process-level sandboxing → Assessment: SYS-REQ-1
- **SYS-1-REQ-2**: Browser shall isolate renderer processes → Assessment: SYS-REQ-2
- **SYS-1-REQ-3**: Browser shall isolate GPU process → Assessment: SYS-REQ-3
- **SYS-1-REQ-4**: Browser shall isolate network service → Assessment: SYS-REQ-4
- **SYS-1-REQ-5**: Browser shall enforce strict filesystem access controls → Assessment: SYS-REQ-5
- **SYS-1-REQ-6**: Browser shall implement permission controls for device hardware APIs → Assessment: SYS-REQ-6
- **SYS-1-REQ-7**: Browser shall enforce geolocation permission requirements → Assessment: SYS-REQ-8
- **SYS-1-REQ-8**: Browser shall enforce camera/microphone access controls with visible indicators → Assessment: SYS-REQ-9
- **SYS-1-REQ-9**: Browser shall restrict clipboard access to require user interaction → Assessment: SYS-REQ-10
- **SYS-1-REQ-10**: Browser shall enforce notification permission management → Assessment: SYS-REQ-11
- **SYS-1-REQ-11**: Browser shall restrict Sensor API access with permissions → Assessment: SYS-REQ-18
- **SYS-1-REQ-12**: Browser shall restrict Battery Status API to prevent fingerprinting → Assessment: SYS-REQ-19
- **SYS-1-REQ-13**: Browser shall enforce hardware resource limits → Assessment: SYS-REQ-20
- **SYS-1-REQ-14**: Browser shall enforce memory isolation → Assessment: SYS-REQ-21
- **SYS-1-REQ-15**: Browser shall implement CPU resource quotas → Assessment: SYS-REQ-22
- **SYS-1-REQ-16**: Browser shall enforce network bandwidth limits → Assessment: SYS-REQ-23
- **SYS-1-REQ-17**: Browser shall enforce storage quota limits → Assessment: SYS-REQ-24
- **SYS-1-REQ-18**: Browser shall implement process priority management → Assessment: SYS-REQ-25
- **SYS-1-REQ-19**: Browser shall prevent sandbox escapes → Assessment: SYS-REQ-26
- **SYS-1-REQ-20**: Browser shall implement speculative execution mitigations → Assessment: SYS-REQ-27
- **SYS-1-REQ-21**: Browser shall implement side-channel mitigations → Assessment: SYS-REQ-28
- **SYS-1-REQ-22**: Browser shall implement accessibility API security controls → Assessment: SYS-REQ-30

#### SYS-2 Requirements (Extended system access for PWAs)

- **SYS-2-REQ-1**: Browser shall implement all SYS-1 requirements
- **SYS-2-REQ-2**: Browser shall enforce equivalent permission controls for PWAs → Assessment: SYS-REQ-7
- **SYS-2-REQ-3**: Browser shall implement USB device access security → Assessment: SYS-REQ-12
- **SYS-2-REQ-4**: Browser shall enforce Bluetooth permission controls → Assessment: SYS-REQ-13
- **SYS-2-REQ-5**: Browser shall implement File System Access API security → Assessment: SYS-REQ-14
- **SYS-2-REQ-6**: Browser shall enforce WebUSB security controls → Assessment: SYS-REQ-15
- **SYS-2-REQ-7**: Browser shall enforce WebBluetooth security → Assessment: SYS-REQ-16
- **SYS-2-REQ-8**: Browser shall implement WebNFC permission management → Assessment: SYS-REQ-17
- **SYS-2-REQ-9**: Browser shall implement hardware token security → Assessment: SYS-REQ-29
- **SYS-2-REQ-10**: Browser shall enforce restricted native messaging with security controls → Assessment: SYS-REQ-31
- **SYS-2-REQ-11**: PWA permissions shall not exceed web context permissions
- **SYS-2-REQ-12**: PWA installation shall not auto-grant extended permissions
- **SYS-2-REQ-13**: PWA uninstallation shall revoke all granted permissions
- **SYS-2-REQ-14**: Browser shall maintain audit log of all PWA permission grants and revocations
- **SYS-2-REQ-15**: Enterprise administrators shall be able to configure PWA permission policies

#### SYS-3 Requirements (Native-equivalent system access)

- **SYS-3-REQ-1**: Browser shall implement baseline sandboxing for renderer processes → Assessment: SYS-REQ-1
- **SYS-3-REQ-2**: Browser shall enforce process isolation → Assessment: SYS-REQ-2
- **SYS-3-REQ-3**: Browser shall implement baseline permission controls for device APIs → Assessment: SYS-REQ-6
- **SYS-3-REQ-4**: Browser shall enforce filesystem access controls → Assessment: SYS-REQ-5
- **SYS-3-REQ-5**: Browser shall implement resource limits to prevent exhaustion → Assessment: SYS-REQ-20
- **SYS-3-REQ-6**: Browser shall implement memory isolation → Assessment: SYS-REQ-21
- **SYS-3-REQ-7**: Browser shall implement CPU quotas → Assessment: SYS-REQ-22
- **SYS-3-REQ-8**: Browser shall enforce storage quotas → Assessment: SYS-REQ-24
- **SYS-3-REQ-9**: Browser shall implement speculative execution mitigations → Assessment: SYS-REQ-27
- **SYS-3-REQ-10**: Browser shall implement side-channel mitigations → Assessment: SYS-REQ-28
- **SYS-3-REQ-11**: Browser shall enforce host OS integration security → Assessment: SYS-REQ-32
- **SYS-3-REQ-12**: Browser shall allow native-equivalent API access with user consent
- **SYS-3-REQ-13**: Browser shall provide transparent UI for all native integration features
- **SYS-3-REQ-14**: Browser shall display security warnings for privileged API access
- **SYS-3-REQ-15**: Browser shall log all extended system access for security auditing
- **SYS-3-REQ-16**: Users shall be able to review and revoke all system permissions
- **SYS-3-REQ-17**: Enterprise administrators shall be able to restrict native-equivalent features
- **SYS-3-REQ-18**: All native integration exceptions shall be documented and auditable

## 5.8 Embedded Browser Security

### 5.8.1 Overview

Embedded browsers (WebView components, browser engines integrated into native applications) present unique security challenges distinct from standalone browsers. While standalone browsers operate as independent applications with their own security boundaries, embedded browsers exist within a host application context where they navigate the security boundary between web content and the host application.

**Key Security Challenges**:

1. **Host-Code Injection**: Malicious web content may attempt to inject code into or manipulate the host application through JavaScript bridge interfaces, custom URL scheme handlers, or exploitation of WebView API vulnerabilities.

2. **User Data Exfiltration**: Web content loaded in an embedded browser may access sensitive data from the host application through insecure bridge configurations, shared storage, or insufficient isolation between web and native contexts.

3. **Insufficient Isolation**: Unlike standalone browsers where all web content is untrusted, embedded browsers often  establish trust relationships with certain content sources while maintaining security boundaries, creating complex policy enforcement challenges.

**Risk Classification**: CRITICAL - Vulnerabilities in embedded browser security can lead to complete compromise of the host application and exfiltration of all user data accessible to the host.

**Applicable Use Cases**: UC-B08 (Embedded Browser Component), UC-B09 (WebView Component in Native Applications), and aspects of UC-B10 (Adapted Browser with Modified Features) when the adaptation includes native component integration.

**References**:

- OWASP Mobile Security Testing Guide - WebViews: https://mas.owasp.org/MASTG/tests/android/MASVS-PLATFORM/MASTG-TEST-0028/
- Android WebView Security Best Practices: https://developer.android.com/develop/ui/views/layout/webapps/webview
- iOS WKWebView Security: https://developer.apple.com/documentation/webkit/wkwebview
- Chromium Embedded Framework Security: https://bitbucket.org/chromiumembedded/cef/wiki/GeneralUsage#markdown-header-security
- Electron Security Best Practices: https://www.electronjs.org/docs/latest/tutorial/security

### 5.8.2 Host Application Boundary Security

**[EMB]** The manufacturer shall implement secure isolation boundaries between embedded browser content and host application code, data, and resources.

**Capability**: JavaScript bridge security, native API exposure control, host data protection, and context isolation

**Conditions**:

- **EMB-0**: No JavaScript bridge or native API exposure (isolated WebView)
- **EMB-1**: Limited JavaScript bridge with explicit allowlist of safe APIs
- **EMB-2**: Extended JavaScript bridge with bidirectional communication
- **EMB-3**: Full integration with access to native capabilities and host data

**Threats**:

- JavaScript injection into host application context
- Unauthorized access to native APIs through bridge exploitation
- Code execution in host process via WebView vulnerabilities
- Cross-context data leakage between web and native layers
- Exploitation of insecure JavaScript bridge configurations
- Bypass of content security policies via native bridges
- Host application credential theft via bridge access
- Native code injection via crafted web content

**Risk**: CRITICAL - Compromise of the host-browser boundary can lead to complete application takeover and data exfiltration

**Requirements**:

#### EMB-0 Requirements (No JavaScript bridge or native API exposure)

- **EMB-0-REQ-1**: Embedded browser shall implement complete context isolation → Assessment: EMB-REQ-4
- **EMB-0-REQ-2**: Embedded browser shall isolate all storage from host application → Assessment: EMB-REQ-12
- **EMB-0-REQ-3**: Embedded browser shall enforce CSP for all web content → Assessment: EMB-REQ-13
- **EMB-0-REQ-4**: Embedded browser shall prevent all web content access to host application objects
- **EMB-0-REQ-5**: No JavaScript bridge or native API exposure mechanism shall exist
- **EMB-0-REQ-6**: Embedded browser shall treat all loaded content as completely untrusted
- **EMB-0-REQ-7**: Host application credentials shall be completely isolated from web context → Assessment: EMB-REQ-8

#### EMB-1 Requirements (Limited JavaScript bridge with explicit allowlist)

- **EMB-1-REQ-1**: JavaScript bridge shall implement explicit API allowlists with per-API access controls → Assessment: EMB-REQ-1
- **EMB-1-REQ-2**: All bridge data shall be validated, sanitized, and type-checked on native side → Assessment: EMB-REQ-2
- **EMB-1-REQ-3**: JavaScript bridge communications shall be logged → Assessment: EMB-REQ-3
- **EMB-1-REQ-4**: Embedded browser shall implement context isolation → Assessment: EMB-REQ-4
- **EMB-1-REQ-5**: Sensitive native APIs shall require explicit user consent → Assessment: EMB-REQ-5
- **EMB-1-REQ-6**: System-level APIs shall not be exposed without additional security controls → Assessment: EMB-REQ-6
- **EMB-1-REQ-7**: JavaScript bridge configuration shall be immutable after initialization → Assessment: EMB-REQ-7
- **EMB-1-REQ-8**: Web content shall not access host credentials, tokens, or keys → Assessment: EMB-REQ-8
- **EMB-1-REQ-9**: Bridge implementations shall be reviewed for injection vulnerabilities → Assessment: EMB-REQ-9
- **EMB-1-REQ-10**: Host shall implement rate limiting on bridge API calls → Assessment: EMB-REQ-10
- **EMB-1-REQ-11**: Bridge shall support granular capability-based permissions → Assessment: EMB-REQ-11
- **EMB-1-REQ-12**: Embedded browser shall isolate storage from host → Assessment: EMB-REQ-12
- **EMB-1-REQ-13**: Host shall enforce CSP for all embedded content → Assessment: EMB-REQ-13
- **EMB-1-REQ-14**: Web content shall not trigger misleading native UI → Assessment: EMB-REQ-15
- **EMB-1-REQ-15**: Host shall implement allowlists rather than denylists for bridge APIs → Assessment: EMB-REQ-16
- **EMB-1-REQ-16**: Only explicitly allowlisted APIs shall be accessible from web content
- **EMB-1-REQ-17**: Bridge API allowlist shall be minimal and documented

#### EMB-2 Requirements (Extended JavaScript bridge with bidirectional communication)

- **EMB-2-REQ-1**: All EMB-1 requirements shall be implemented
- **EMB-2-REQ-2**: Bridge communications crossing process boundaries shall be encrypted → Assessment: EMB-REQ-14
- **EMB-2-REQ-3**: Bridge shall implement granular permissions → Assessment: EMB-REQ-11
- **EMB-2-REQ-4**: Host shall implement comprehensive rate limiting → Assessment: EMB-REQ-10
- **EMB-2-REQ-5**: All bridge communications shall be logged with full audit trails → Assessment: EMB-REQ-3
- **EMB-2-REQ-6**: Bidirectional bridge calls shall maintain same security controls in both directions
- **EMB-2-REQ-7**: Web content callback handlers shall be validated before invocation
- **EMB-2-REQ-8**: Bridge shall implement message queuing with integrity protection
- **EMB-2-REQ-9**: Host shall monitor bridge traffic for anomalies
- **EMB-2-REQ-10**: Enterprise administrators shall be able to configure bridge API policies

#### EMB-3 Requirements (Full integration with native capabilities)

- **EMB-3-REQ-1**: Baseline EMB-1 security controls shall be maintained
- **EMB-3-REQ-2**: Bridge shall implement comprehensive input validation → Assessment: EMB-REQ-2
- **EMB-3-REQ-3**: Bridge shall log all operations with security context → Assessment: EMB-REQ-3
- **EMB-3-REQ-4**: Sensitive native operations shall require user consent → Assessment: EMB-REQ-5
- **EMB-3-REQ-5**: System-level APIs shall have strict additional controls → Assessment: EMB-REQ-6
- **EMB-3-REQ-6**: Bridge implementations shall undergo security review → Assessment: EMB-REQ-9
- **EMB-3-REQ-7**: Rate limiting shall prevent bridge API abuse → Assessment: EMB-REQ-10
- **EMB-3-REQ-8**: Full integration shall not bypass core security boundaries
- **EMB-3-REQ-9**: User shall be informed of all native capabilities granted to web content
- **EMB-3-REQ-10**: User shall be able to review and revoke native API access
- **EMB-3-REQ-11**: All native integrations shall be documented and auditable
- **EMB-3-REQ-12**: Enterprise policies shall be able to restrict native integration scope

### 5.8.3 Content Source Trust Management

**[EMB]** The manufacturer shall implement mechanisms to establish and enforce trust relationships between embedded browser content sources and the host application.

**Capability**: Content source validation, certificate pinning for embedded content, subresource integrity, and trust boundary enforcement

**Conditions**:

- **EMB-0**: All content treated as untrusted (public internet)
- **EMB-1**: Trusted domains with certificate validation
- **EMB-2**: Certificate pinning for specific trusted origins
- **EMB-3**: Local/bundled content with cryptographic verification

**Threats**:

- Man-in-the-middle attacks against trusted content sources
- Loading of malicious content from compromised trusted domains
- Bypass of trust boundaries through redirect chains
- Subresource substitution attacks
- DNS hijacking of embedded content sources
- Certificate authority compromise affecting trusted origins
- Mixed content attacks (trusted page loading untrusted resources)
- Cache poisoning affecting embedded content

**Risk**: CRITICAL - Compromise of trusted content sources can lead to injection of malicious code with elevated privileges

**Requirements**:

#### EMB-0 Requirements (All content treated as untrusted - public internet)

- **EMB-0-REQ-1**: All content shall be treated as completely untrusted
- **EMB-0-REQ-2**: Embedded browser shall validate SSL/TLS certificates for all remote content → Assessment: EMB-REQ-17
- **EMB-0-REQ-3**: Embedded browser shall prevent all mixed content → Assessment: EMB-REQ-21
- **EMB-0-REQ-4**: Certificate validation failures shall block content loading → Assessment: EMB-REQ-26
- **EMB-0-REQ-5**: Network security configuration shall prevent cleartext traffic → Assessment: EMB-REQ-27
- **EMB-0-REQ-6**: Trust boundary violations shall trigger security events → Assessment: EMB-REQ-32
- **EMB-0-REQ-7**: No content origin shall have privileged access
- **EMB-0-REQ-8**: All CSP policies shall be strictly enforced without exceptions

#### EMB-1 Requirements (Trusted domains with certificate validation)

- **EMB-1-REQ-1**: Embedded browser shall validate SSL/TLS certificates for all remote content → Assessment: EMB-REQ-17
- **EMB-1-REQ-2**: Host shall implement allowlist of trusted content origins → Assessment: EMB-REQ-18
- **EMB-1-REQ-3**: Embedded browser shall prevent mixed content → Assessment: EMB-REQ-21
- **EMB-1-REQ-4**: Trust decisions shall be logged with full context → Assessment: EMB-REQ-22
- **EMB-1-REQ-5**: Host shall implement redirect chain validation → Assessment: EMB-REQ-24
- **EMB-1-REQ-6**: Embedded browser shall enforce HSTS for trusted origins → Assessment: EMB-REQ-25
- **EMB-1-REQ-7**: Certificate failures shall trigger immediate notification and blocking → Assessment: EMB-REQ-26
- **EMB-1-REQ-8**: Network security config shall prevent cleartext to trusted domains → Assessment: EMB-REQ-27
- **EMB-1-REQ-9**: Trusted content shall not load untrusted third-party content without CSP → Assessment: EMB-REQ-28
- **EMB-1-REQ-10**: Trust boundary violations shall trigger security events → Assessment: EMB-REQ-32
- **EMB-1-REQ-11**: Only explicitly allowlisted origins shall be considered trusted
- **EMB-1-REQ-12**: Trust allowlist shall be immutable by web content

#### EMB-2 Requirements (Certificate pinning for specific trusted origins)

- **EMB-2-REQ-1**: All EMB-1 requirements shall be implemented
- **EMB-2-REQ-2**: Embedded browser shall implement certificate pinning for critical origins → Assessment: EMB-REQ-17
- **EMB-2-REQ-3**: Embedded browser shall enforce SRI for external scripts from trusted content → Assessment: EMB-REQ-19
- **EMB-2-REQ-4**: Certificate pinning shall include backup pins and rotation mechanisms → Assessment: EMB-REQ-20
- **EMB-2-REQ-5**: Trust policies shall be configurable per browser instance → Assessment: EMB-REQ-29
- **EMB-2-REQ-6**: Embedded browser shall implement certificate transparency verification → Assessment: EMB-REQ-30
- **EMB-2-REQ-7**: Host shall detect and prevent DNS rebinding attacks → Assessment: EMB-REQ-31
- **EMB-2-REQ-8**: Pin configuration shall be immutable after initialization
- **EMB-2-REQ-9**: Pinning violations shall immediately block content loading
- **EMB-2-REQ-10**: Pin rotation procedures shall be documented and tested

#### EMB-3 Requirements (Local/bundled content with cryptographic verification)

- **EMB-3-REQ-1**: Baseline EMB-1 certificate validation shall apply to all remote content
- **EMB-3-REQ-2**: Embedded browser shall verify cryptographic signatures for local/bundled content → Assessment: EMB-REQ-23
- **EMB-3-REQ-3**: Embedded browser shall enforce SRI for all external scripts → Assessment: EMB-REQ-19
- **EMB-3-REQ-4**: Certificate pinning shall be enforced for remote trusted origins → Assessment: EMB-REQ-17, EMB-REQ-20
- **EMB-3-REQ-5**: Trust decisions shall be logged comprehensively → Assessment: EMB-REQ-22
- **EMB-3-REQ-6**: Trust policies shall be configurable per instance → Assessment: EMB-REQ-29
- **EMB-3-REQ-7**: DNS rebinding prevention shall be enforced → Assessment: EMB-REQ-31
- **EMB-3-REQ-8**: Trust boundary violations shall trigger detailed security events → Assessment: EMB-REQ-32
- **EMB-3-REQ-9**: Local content signature verification shall use secure algorithms (RSA-2048+, ECDSA P-256+)
- **EMB-3-REQ-10**: Modified local content shall fail signature verification and be rejected
- **EMB-3-REQ-11**: Signing keys for local content shall be protected from extraction
- **EMB-3-REQ-12**: Hybrid deployments (local + remote) shall maintain strictest security controls for each content type

**References**:

- OWASP Mobile Top 10 - M1: Improper Platform Usage: https://owasp.org/www-project-mobile-top-10/
- CWE-749: Exposed Dangerous Method or Function: https://cwe.mitre.org/data/definitions/749.html
- CWE-940: Improper Verification of Source of a Communication Channel: https://cwe.mitre.org/data/definitions/940.html
- Android Network Security Configuration: https://developer.android.com/training/articles/security-config
- iOS App Transport Security: https://developer.apple.com/documentation/security/preventing_insecure_network_connections
- Certificate Pinning Best Practices: https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
- Electron Context Isolation: https://www.electronjs.org/docs/latest/tutorial/context-isolation

# 6 Technical Security Assessments

This chapter provides detailed technical assessment procedures for verifying conformance with the security requirements specified in Chapter 5. Each assessment follows a structured methodology designed to produce objective, repeatable results suitable for third-party conformity assessment.

## 6.1 Domain and Origin Isolation Assessments

This section covers assessment procedures for requirements DOM-REQ-1 through DOM-REQ-12, addressing site isolation, origin-based security boundaries, cross-origin resource sharing, and related isolation mechanisms.

### Assessment: DOM-REQ-1 (Process-per-site isolation)

**Reference**: DOM-REQ-1 - Browser shall implement process-per-site isolation

**Given**: A conformant browser with site isolation capabilities (DOM-1 or higher)

**Task**: Verify that the browser enforces operating system-level process isolation between distinct sites to prevent compromise of one site from affecting other sites, and to enable OS-level security mechanisms (ASLR, sandboxing, memory protection) to provide defense-in-depth against web-based attacks.

**Verification**:

1. Open the browser and navigate to three distinct origins: https://example.com, https://test.com, and https://example.org
2. In each origin, open the browser's task manager or use platform process monitoring tools (Process Explorer on Windows, Activity Monitor on macOS, ps/top on Linux)
3. Identify the renderer processes associated with each origin
4. Record the Process IDs (PIDs) for each origin's renderer process
5. Navigate from https://example.com to https://example.com/page2 and verify the PID remains the same
6. Navigate from https://example.com to https://different.example.com (different subdomain, same site) and verify the PID remains the same or changes according to documented site isolation policy
7. Create cross-origin iframes (example.com embedding test.com) and verify they run in separate processes
8. Confirm that each distinct site (eTLD+1) is allocated a separate renderer process
9. Verify that same-site navigations reuse the same renderer process
10. Check that cross-origin iframes are isolated in separate processes from their embedder
11. Validate that process separation is maintained throughout the browser session
12. Review browser task manager or process monitoring tools to confirm distinct processes for distinct sites

**Pass Criteria**: All distinct sites use separate renderer processes AND cross-origin iframes are isolated in separate processes

**Fail Criteria**: Any two distinct sites share a renderer process OR cross-origin iframe runs in the same process as embedder

**Evidence**: Screenshots of browser task manager showing distinct PIDs for distinct sites, process tree diagrams, video recordings of process creation during navigation

**References**:

- Chromium Site Isolation Architecture: https://www.chromium.org/Home/chromium-security/site-isolation/
- Process Models for Web Browsers: https://www.chromium.org/developers/design-documents/process-models/
- Firefox Project Fission: https://wiki.mozilla.org/Project_Fission

### Assessment: DOM-REQ-2 (Cross-origin read blocking)

**Reference**: DOM-REQ-2 - Browser shall enforce Cross-Origin Read Blocking (CORB)

**Given**: A conformant browser with DOM-1 or higher capability

**Task**: Verify that the browser prevents attackers from using script/image/stylesheet tags to read sensitive cross-origin data (JSON, HTML, XML) that lacks CORS headers, protecting against Spectre-style attacks and cross-site data leakage where malicious pages attempt to load victim resources into contexts that could expose response data through side channels.

**Verification**:

1. Set up a test web server serving resources with various MIME types (HTML, JSON, XML, images, scripts)
2. Create a test page at https://attacker.com that attempts to load resources from https://victim.com using various methods:
   - `<script src="https://victim.com/sensitive.json">`
   - `<img src="https://victim.com/sensitive.json">`
   - `<link rel="stylesheet" href="https://victim.com/sensitive.html">`
   - `fetch()` requests without CORS headers
3. Configure https://victim.com to serve JSON/HTML/XML resources without CORS headers
4. Monitor network traffic using browser DevTools to capture CORB decisions
5. Verify that cross-origin requests for JSON/HTML/XML are blocked when served with incorrect MIME types
6. Verify that legitimate cross-origin image/script/CSS loads still succeed
7. Test edge cases: nosniff headers, ambiguous MIME types, empty responses
8. Confirm that JSON, HTML, and XML responses without CORS headers are blocked from cross-origin script contexts
9. Verify that browser console shows CORB warning messages with details of blocked resources
10. Check that network panel shows resources blocked with CORB designation
11. Validate that legitimate cross-origin subresources (images, scripts with correct MIME types) load successfully
12. Confirm that `X-Content-Type-Options: nosniff` is respected in CORB decisions

**Pass Criteria**: All cross-origin HTML/JSON/XML loads without CORS headers are blocked from script contexts AND browser logs CORB blocking events

**Fail Criteria**: Any JSON/HTML/XML resource is readable cross-origin without CORS headers OR no CORB enforcement is observable

**Evidence**: Browser console screenshots showing CORB warnings, network panel captures showing blocked resources, packet captures demonstrating data was fetched but not exposed to scripts, test server logs

**References**:

- CORB Specification: https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md
- Fetch Metadata Request Headers: https://www.w3.org/TR/fetch-metadata/
- MIME Sniffing Standard: https://mimesniff.spec.whatwg.org/

### Assessment: DOM-REQ-3 (Strict origin policy enforcement)

**Reference**: DOM-REQ-3 - Browser shall prevent cross-origin DOM access without explicit consent

**Given**: A conformant browser with DOM-0 or higher capability

**Task**: Verify that the browser enforces the Same-Origin Policy to prevent scripts from one origin from reading or manipulating the DOM of another origin, protecting against cross-site scripting attacks where malicious sites attempt to steal sensitive data or hijack user sessions by accessing cross-origin window objects, documents, or storage.

**Verification**:

1. Create two test pages: https://site-a.com/test.html and https://site-b.com/test.html
2. From site-a, open site-b in a new window using `window.open()`
3. Attempt cross-origin DOM access from site-a to site-b window:
   - `otherWindow.document` - attempt to access document
   - `otherWindow.localStorage` - attempt to access storage
   - `otherWindow.location.href = "javascript:..."` - attempt navigation hijacking
   - `otherWindow.frames[0]` - attempt to access frames
4. Verify that all cross-origin DOM access attempts throw SecurityError exceptions
5. Test that same-origin window access succeeds
6. Test `window.postMessage()` as the legitimate cross-origin communication channel
7. Verify that `Location` object allows limited cross-origin access (href setter only) but not href getter
8. Confirm that all cross-origin DOM access attempts throw SecurityError exceptions
9. Verify that browser console logs SecurityError with clear origin mismatch messages
10. Check that same-origin window access succeeds without errors
11. Validate that postMessage() works correctly for cross-origin communication
12. Confirm that Location.href can be set cross-origin but not read

**Pass Criteria**: All cross-origin DOM property access attempts throw SecurityError AND postMessage provides functional cross-origin communication

**Fail Criteria**: Any cross-origin DOM property is readable/writable OR no exception is thrown

**Evidence**: Browser console screenshots showing SecurityError exceptions, video demonstration of test execution, automated test results from Web Platform Tests

**References**:

- HTML Standard - Cross-origin objects: https://html.spec.whatwg.org/multipage/browsers.html#cross-origin-objects
- Same-Origin Policy (MDN): https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
- Web Platform Tests - Origin isolation: https://github.com/web-platform-tests/wpt/tree/master/html/browsers/origin

### Assessment: DOM-REQ-4 (CORS preflight enforcement)

**Reference**: DOM-REQ-4 - Browser shall enforce CORS preflight for non-simple requests

**Given**: A conformant browser with DOM-1 or higher capability

**Task**: Verify that the browser enforces CORS preflight checks for potentially dangerous cross-origin requests (non-simple methods, custom headers) to prevent attackers from triggering unauthorized state-changing operations on victim servers, ensuring that servers have an opportunity to reject requests before they execute and protecting against CSRF-style attacks that bypass simple request restrictions.

**Verification**:

1. Set up a test server that logs all incoming requests including OPTIONS requests
2. Create test pages that make various fetch() requests to cross-origin servers:
   - Simple requests (GET with simple headers)
   - Non-simple requests (PUT, DELETE, PATCH methods)
   - Requests with custom headers (X-Custom-Header)
   - Requests with credentials (cookies)
3. Monitor network traffic to verify preflight OPTIONS requests are sent before non-simple requests
4. Configure the server to respond with various CORS header combinations:
   - Correct CORS headers (Access-Control-Allow-Origin, Allow-Methods, Allow-Headers)
   - Missing CORS headers
   - Incorrect origin in CORS headers
   - Expired preflight cache (Access-Control-Max-Age: 0)
5. Verify that actual requests only proceed after successful preflight
6. Test preflight caching behavior
7. Confirm that OPTIONS preflight requests are sent before all non-simple cross-origin requests
8. Verify that actual requests only proceed after successful preflight response with matching CORS headers
9. Check that browser blocks requests when preflight fails or returns incorrect headers
10. Validate that preflight responses are cached according to Access-Control-Max-Age
11. Confirm that simple requests proceed without preflight but are still subject to CORS checks on response

**Pass Criteria**: All non-simple requests are preceded by OPTIONS preflight AND requests fail when preflight response lacks appropriate CORS headers

**Fail Criteria**: Non-simple requests proceed without preflight OR requests succeed despite missing CORS headers

**Evidence**: Network panel screenshots showing OPTIONS requests before actual requests, server logs demonstrating preflight sequence, packet captures with timing analysis

**References**:

- Fetch Standard - CORS protocol: https://fetch.spec.whatwg.org/#http-cors-protocol
- CORS (MDN): https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
- Preflight request specification: https://fetch.spec.whatwg.org/#cors-preflight-request

### Assessment: DOM-REQ-5 (Cookie SameSite attribute enforcement)

**Reference**: DOM-REQ-5 - Browser shall enforce SameSite cookie attribute

**Given**: A conformant browser with DOM-1 or higher capability

**Task**: Verify that the browser enforces SameSite cookie restrictions to prevent Cross-Site Request Forgery (CSRF) attacks where malicious sites trigger authenticated requests to victim applications by controlling when cookies are sent in cross-site contexts, with Strict preventing all cross-site transmission, Lax allowing safe top-level navigations, and None requiring explicit Secure flag.

**Verification**:

1. Set up two test domains: https://site-a.com and https://site-b.com
2. Configure site-a to set cookies with various SameSite attributes:
   - `Set-Cookie: session=abc123; SameSite=Strict; Secure`
   - `Set-Cookie: tracking=xyz789; SameSite=Lax; Secure`
   - `Set-Cookie: legacy=old; Secure` (no SameSite)
   - `Set-Cookie: none=test; SameSite=None; Secure`
3. From site-b, perform various cross-site requests to site-a:
   - Top-level navigation (clicking link)
   - Embedded resources (images, iframes)
   - JavaScript fetch() POST request
   - Form submission (GET and POST)
4. Monitor network traffic to verify which cookies are sent in each scenario
5. Test the default SameSite behavior for cookies without explicit attribute (should be Lax)
6. Verify that SameSite=None requires Secure attribute
7. Confirm that SameSite=Strict cookies are never sent in cross-site contexts
8. Verify that SameSite=Lax cookies are sent only in top-level navigation (GET)
9. Check that SameSite=None cookies are sent in all contexts but require Secure attribute
10. Validate that cookies without SameSite attribute default to Lax behavior
11. Confirm that browser rejects SameSite=None cookies without Secure attribute

**Pass Criteria**: Cookie transmission matches SameSite attribute policy for all test cases AND default behavior is Lax

**Fail Criteria**: Any cookie is sent in violation of its SameSite policy OR SameSite=None works without Secure

**Evidence**: Network panel screenshots showing Cookie headers in different contexts, DevTools Application tab showing cookie attributes, test server logs of received cookies

**References**:

- RFC 6265bis - SameSite Cookies: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis
- SameSite Cookies Explained (web.dev): https://web.dev/samesite-cookies-explained/
- Cookie SameSite attribute (MDN): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite

### Assessment: DOM-REQ-6 (Origin-bound storage isolation)

**Reference**: DOM-REQ-6 - Browser shall isolate localStorage and IndexedDB per origin

**Given**: A conformant browser with DOM-0 or higher capability

**Task**: Verify that the browser enforces complete storage isolation between origins to prevent malicious sites from reading sensitive user data (session tokens, personal information) stored by other applications, ensuring that origin boundaries (scheme, host, port) create impermeable barriers for localStorage and IndexedDB access.

**Verification**:

1. Create test pages at multiple origins: https://example.com, https://example.org, http://example.com, https://sub.example.com
2. In each origin, write distinct data to localStorage:
   ```javascript
   localStorage.setItem('origin-test', location.origin);
   localStorage.setItem('timestamp', Date.now());
   ```
3. In each origin, create an IndexedDB database with a distinct name and store origin-specific data
4. Attempt to read localStorage and IndexedDB from each origin
5. Verify that each origin only sees its own storage
6. Test subdomain isolation (example.com vs sub.example.com)
7. Test protocol isolation (https vs http)
8. Test port isolation (example.com:443 vs example.com:8080)
9. Clear storage for one origin and verify other origins' storage is unaffected
10. Confirm that each origin has completely isolated localStorage namespace
11. Verify that each origin has completely isolated IndexedDB namespace
12. Check that different subdomains cannot access each other's storage
13. Validate that different protocols (http vs https) have separate storage
14. Confirm that different ports have separate storage
15. Verify that storage clearing is scoped to single origin

**Pass Criteria**: No origin can read another origin's localStorage or IndexedDB AND all origin components (scheme, host, port) contribute to isolation boundary

**Fail Criteria**: Any cross-origin storage access succeeds OR incomplete origin matching (e.g., ignoring port)

**Evidence**: Browser DevTools Application tab screenshots showing storage contents per origin, console logs demonstrating isolation, automated test results

**References**:

- Web Storage API specification: https://html.spec.whatwg.org/multipage/webstorage.html
- IndexedDB API specification: https://w3c.github.io/IndexedDB/
- Origin definition: https://html.spec.whatwg.org/multipage/origin.html#concept-origin

### Assessment: DOM-REQ-7 (Frame sandboxing support)

**Reference**: DOM-REQ-7 - Browser shall support iframe sandbox attribute

**Given**: A conformant browser with DOM-1 or higher capability

**Task**: Verify that the browser implements iframe sandbox restrictions to mitigate risks from untrusted content by allowing developers to apply least-privilege principles to embedded frames, preventing malicious iframes from executing scripts, accessing parent windows, navigating the top frame, or abusing other dangerous capabilities unless explicitly permitted.

**Verification**:

1. Create test pages with iframes using various sandbox configurations:
   ```html
   <iframe sandbox src="test.html"></iframe>
   <iframe sandbox="allow-scripts" src="test.html"></iframe>
   <iframe sandbox="allow-scripts allow-same-origin" src="test.html"></iframe>
   <iframe sandbox="allow-forms allow-popups" src="test.html"></iframe>
   ```
2. In each sandboxed iframe, attempt various actions:
   - JavaScript execution (alert, console.log)
   - Form submission
   - Opening popups (window.open)
   - Accessing parent window
   - Accessing localStorage
   - Top navigation (top.location = ...)
3. Verify that only explicitly allowed capabilities work
4. Test that sandbox="" (empty) applies strictest restrictions
5. Test CSP sandbox directive equivalence
6. Verify unique origin treatment for sandboxed iframes without allow-same-origin
7. Confirm that sandbox attribute restricts capabilities according to specified tokens
8. Verify that scripts are blocked unless allow-scripts is present
9. Check that same-origin access is blocked unless allow-same-origin is present
10. Validate that sandboxed frames without allow-same-origin have unique opaque origin
11. Confirm that browser console logs security errors for blocked actions
12. Verify that CSP sandbox directive provides equivalent restrictions

**Pass Criteria**: All tested restrictions are enforced according to sandbox tokens AND browser logs security errors for blocked actions

**Fail Criteria**: Any capability works without corresponding allow-* token OR no restrictions are observed

**Evidence**: Browser console screenshots showing blocked actions, DevTools showing unique origin for sandboxed frames, test results demonstrating each sandbox token

**References**:

- HTML Standard - Sandboxing: https://html.spec.whatwg.org/multipage/iframe-embed-object.html#attr-iframe-sandbox
- CSP sandbox directive: https://www.w3.org/TR/CSP3/#directive-sandbox
- iframe sandbox (MDN): https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox

### Assessment: DOM-REQ-8 (Opaque origin handling)

**Reference**: DOM-REQ-8 - Browser shall treat sandboxed and data: origins as opaque

**Given**: A conformant browser with DOM-0 or higher capability

**Task**: Verify that the browser treats sandboxed iframes and data: URLs as having opaque (unique, unguessable) origins that cannot access storage or credentials, preventing untrusted content from stealing sensitive data or establishing persistent state, while ensuring that each opaque origin is internally unique to prevent two untrusted contexts from communicating even though both serialize as "null".

**Verification**:

1. Create test scenarios for opaque origins:
   - Sandboxed iframe without allow-same-origin: `<iframe sandbox="allow-scripts" src="...">`
   - data: URL navigation: `window.open('data:text/html,<h1>Test</h1>')`
   - Blob URL: `URL.createObjectURL(new Blob(['...'], {type: 'text/html'}))`
2. In each opaque origin context, attempt to:
   - Access localStorage/sessionStorage (should throw SecurityError)
   - Access IndexedDB (should throw SecurityError)
   - Make fetch() requests (should succeed but not send credentials)
   - Access parent window (should be blocked for sandboxed frames)
3. Verify that opaque origins serialize as "null" in `window.origin`
4. Test that two distinct opaque origins cannot access each other even though both serialize as "null"
5. Verify that cookies are not sent/received from opaque origins
6. Confirm that opaque origins report window.origin as "null"
7. Verify that opaque origins cannot access localStorage, sessionStorage, or IndexedDB
8. Check that opaque origins do not send or receive cookies
9. Validate that each opaque origin is unique and cannot access other opaque origins
10. Confirm that fetch requests from opaque origins work but without credentials

**Pass Criteria**: All storage APIs throw SecurityError in opaque origins AND window.origin reports "null" AND cookies are not sent

**Fail Criteria**: Any storage access succeeds from opaque origin OR cookies are sent/received

**Evidence**: Console screenshots showing SecurityError exceptions, network captures showing missing cookies, DevTools Application tab showing empty storage

**References**:

- HTML Standard - Opaque origins: https://html.spec.whatwg.org/multipage/origin.html#concept-origin-opaque
- data: URL security: https://datatracker.ietf.org/doc/html/rfc2397
- Fetch - CORS and credentials: https://fetch.spec.whatwg.org/#http-cors-protocol

### Assessment: DOM-REQ-9 (CORP for cross-origin isolation)

**Reference**: DOM-REQ-9 - Browser shall support Cross-Origin-Resource-Policy header

**Given**: A conformant browser with DOM-2 or higher capability

**Task**: Verify that the browser enforces Cross-Origin-Resource-Policy (CORP) headers to allow servers to protect their resources from being loaded by cross-origin pages, defending against Spectre-style attacks where malicious sites embed victim resources to leak data through side channels, and enabling servers to opt into stronger isolation guarantees for sensitive content.

**Verification**:

1. Set up test servers on multiple origins (site-a.com, site-b.com, cdn.example.com)
2. Configure site-a to serve resources with various CORP headers:
   - `Cross-Origin-Resource-Policy: same-origin`
   - `Cross-Origin-Resource-Policy: same-site`
   - `Cross-Origin-Resource-Policy: cross-origin`
3. From site-b, attempt to load resources from site-a:
   ```html
   <img src="https://site-a.com/image-same-origin.png">
   <script src="https://site-a.com/script-same-site.js"></script>
   <iframe src="https://site-a.com/frame-cross-origin.html"></iframe>
   ```
4. Verify blocking behavior based on CORP header
5. Test CORP interaction with CORS headers
6. Verify that CORP applies to all resource types (images, scripts, frames, fetch)
7. Test CORP enforcement in cross-origin isolated contexts (COOP+COEP)
8. Confirm that resources with CORP: same-origin are blocked from cross-origin loads
9. Verify that resources with CORP: same-site are blocked from cross-site loads but allowed same-site
10. Check that resources with CORP: cross-origin load from any origin
11. Validate that browser console shows CORP blocking errors with clear messages
12. Confirm that CORP is enforced for all resource types
13. Verify that CORP is enforced even for opaque responses (no-cors mode)

**Pass Criteria**: All CORP policies are enforced according to specification AND browser logs blocking errors

**Fail Criteria**: Any resource loads in violation of its CORP header OR no CORP enforcement is observable

**Evidence**: Network panel showing blocked resources, console screenshots showing CORP errors, test results demonstrating same-origin/same-site/cross-origin behavior

**References**:

- CORP Specification: https://fetch.spec.whatwg.org/#cross-origin-resource-policy-header
- Cross-Origin Isolation guide: https://web.dev/coop-coep/
- CORP (MDN): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy

### Assessment: DOM-REQ-10 (COOP enforcement)

**Reference**: DOM-REQ-10 - Browser shall enforce Cross-Origin-Opener-Policy

**Given**: A conformant browser with DOM-2 or higher capability

**Task**: Verify that the browser enforces Cross-Origin-Opener-Policy (COOP) to prevent cross-origin documents from sharing browsing context groups and accessing each other through window.opener references, protecting against Spectre-style attacks by enabling process isolation and allowing sites to opt into cross-origin isolation that grants access to powerful features like SharedArrayBuffer.

**Verification**:

1. Create test pages with various COOP headers:
   - `Cross-Origin-Opener-Policy: same-origin`
   - `Cross-Origin-Opener-Policy: same-origin-allow-popups`
   - `Cross-Origin-Opener-Policy: unsafe-none` (default)
2. Test window.opener relationships:
   - Page A (COOP: same-origin) opens Page B (no COOP) → opener should be null
   - Page A (no COOP) opens Page B (COOP: same-origin) → opener should be null
   - Page A (COOP: same-origin) opens Page B (same-origin with COOP) → opener should work
3. Verify browsing context group isolation
4. Test that cross-origin-isolated pages cannot be in the same browsing context group as non-isolated pages
5. Verify SharedArrayBuffer availability in cross-origin isolated contexts
6. Test COOP reporting endpoint functionality
7. Confirm that COOP: same-origin severs opener relationship with cross-origin pages
8. Verify that COOP: same-origin-allow-popups preserves opener for popups but not navigations
9. Check that cross-origin isolated pages (COOP + COEP) get access to high-resolution timers and SharedArrayBuffer
10. Validate that browser process allocation reflects browsing context group isolation
11. Confirm that violation reports are sent to reporting endpoint when configured

**Pass Criteria**: Opener relationship is severed as specified by COOP policy AND cross-origin isolation enables SharedArrayBuffer

**Fail Criteria**: Opener relationship persists in violation of COOP policy OR SharedArrayBuffer unavailable in properly isolated context

**Evidence**: Console logs showing null window.opener, DevTools showing browsing context groups, demonstration of SharedArrayBuffer availability, network captures of violation reports

**References**:

- COOP Specification: https://html.spec.whatwg.org/multipage/origin.html#cross-origin-opener-policies
- Cross-Origin Isolation guide: https://web.dev/coop-coep/
- SharedArrayBuffer and cross-origin isolation: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer

### Assessment: DOM-REQ-11 (COEP enforcement)

**Reference**: DOM-REQ-11 - Browser shall enforce Cross-Origin-Embedder-Policy

**Given**: A conformant browser with DOM-2 or higher capability

**Task**: Verify that the browser enforces Cross-Origin-Embedder-Policy (COEP) to ensure that all cross-origin resources loaded by a document have explicitly opted in via CORP or CORS headers, preventing the document from inadvertently loading attacker-controlled resources that could be used in Spectre-style side-channel attacks, and enabling cross-origin isolation when combined with COOP.

**Verification**:

1. Create a test page with COEP header: `Cross-Origin-Embedder-Policy: require-corp`
2. From this page, attempt to load various cross-origin resources:
   - Image without CORP/CORS: `<img src="https://cross-origin.com/image.png">`
   - Image with CORP: `<img src="https://cross-origin.com/image-with-corp.png">` (CORP: cross-origin)
   - Script without CORS: `<script src="https://cross-origin.com/script.js">`
   - Script with CORS: `<script src="..." crossorigin="anonymous">` (with proper CORS headers)
   - Iframe without COEP: `<iframe src="https://cross-origin.com/page.html">`
   - Iframe with COEP: `<iframe src="...">` (page has COEP header)
3. Verify blocking of resources without CORP/CORS
4. Test COEP: credentialless as alternative to require-corp
5. Verify that combining COOP + COEP enables cross-origin isolation
6. Test COEP violation reporting
7. Confirm that resources without CORP or CORS are blocked when page has COEP: require-corp
8. Verify that resources with CORP: cross-origin load successfully
9. Check that resources with CORS and crossorigin attribute load successfully
10. Validate that iframes without COEP are blocked from embedding in COEP page
11. Confirm that browser console shows COEP blocking errors
12. Verify that COOP + COEP combination enables self.crossOriginIsolated === true

**Pass Criteria**: All resources without CORP/CORS are blocked AND cross-origin isolation is achieved with COOP+COEP

**Fail Criteria**: Any resource without CORP/CORS loads successfully OR cross-origin isolation not achieved despite proper headers

**Evidence**: Network panel showing blocked resources, console screenshots showing COEP errors, JavaScript console showing self.crossOriginIsolated === true

**References**:

- COEP Specification: https://html.spec.whatwg.org/multipage/origin.html#coep
- Cross-Origin Isolation: https://web.dev/coop-coep/
- COEP (MDN): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy

### Assessment: DOM-REQ-12 (Document.domain deprecation)

**Reference**: DOM-REQ-12 - Browser shall restrict or remove document.domain setter

**Given**: A conformant browser with DOM-1 or higher capability

**Task**: Verify that the browser restricts or removes the document.domain setter to eliminate a legacy same-origin policy relaxation mechanism that undermines site isolation, prevents origin-keyed agent clustering for performance, and creates security risks by allowing subdomains to arbitrarily merge their security boundaries, requiring sites to explicitly opt-out of modern isolation to use this deprecated feature.

**Verification**:

1. Create test pages on related subdomains: https://sub1.example.com and https://sub2.example.com
2. Attempt to relax same-origin policy using document.domain:
   ```javascript
   // On both sub1.example.com and sub2.example.com
   document.domain = 'example.com';
   ```
3. Verify that document.domain setter is either:
   - Removed entirely (throws error or no-op)
   - Gated behind Origin-Agent-Cluster: ?0 header
4. Test that pages with `Origin-Agent-Cluster: ?1` (default) cannot set document.domain
5. Verify that failing to set document.domain prevents cross-subdomain DOM access
6. Test browser console warnings about document.domain deprecation
7. Confirm that document.domain setter is unavailable or no-op by default
8. Verify that pages can only set document.domain if they explicitly opt-out via Origin-Agent-Cluster: ?0
9. Check that browser console shows deprecation warnings when document.domain is accessed
10. Validate that cross-subdomain access fails when document.domain is disabled
11. Confirm that Origin-Agent-Cluster header controls document.domain availability

**Pass Criteria**: document.domain is restricted by default (requires explicit opt-out) AND browser shows deprecation warnings

**Fail Criteria**: document.domain works unconditionally OR no deprecation warnings shown

**Evidence**: Console screenshots showing errors/warnings, test results showing cross-subdomain access blocked, DevTools showing Origin-Agent-Cluster header processing

**References**:

- document.domain deprecation: https://developer.chrome.com/blog/immutable-document-domain/
- Origin-Agent-Cluster header: https://html.spec.whatwg.org/multipage/origin.html#origin-agent-cluster
- HTML Standard - Origin-keyed agent clusters: https://html.spec.whatwg.org/multipage/origin.html#origin-keyed-agent-clusters

### Assessment: DOM-REQ-13 (Enterprise origin isolation policy configuration)

**Reference**: DOM-2-REQ-11 - Administrators shall be able to configure origin isolation policies via enterprise policy

**Given**: A conformant browser with DOM-2 or higher capability in an enterprise environment

**Task**: Verify that enterprise administrators can configure origin isolation policies to accommodate legitimate business requirements for cross-origin interactions while maintaining security boundaries, enabling organizations to define exceptions for trusted domains or internal applications without requiring code changes or browser rebuilds, supporting controlled relaxation of isolation for specific business scenarios.

**Verification**:

1. Access the browser's enterprise policy management interface or configuration file
2. Identify available policies related to origin isolation (e.g., SitePerProcessMode, IsolateOriginsMode, CrossOriginPolicyExceptions)
3. Configure a policy to modify default isolation behavior for specific origins or domains
4. Deploy the policy through enterprise management tools (Group Policy, MDM, configuration management)
5. Verify that the browser applies the configured policy on startup
6. Test that the configured isolation exceptions work as intended for specified origins
7. Verify that origins not covered by the policy maintain default isolation
8. Test that policy changes require browser restart or profile reload to take effect
9. Confirm that policy-configured exceptions are logged in browser diagnostic logs
10. Verify that users cannot override enterprise-configured isolation policies
11. Test that malformed policies are rejected with clear error messages
12. Validate that policy configuration is documented in enterprise administration guides

**Pass Criteria**: Enterprise policies for origin isolation are available AND policies can be centrally deployed AND configured exceptions work as specified AND non-configured origins maintain default isolation

**Fail Criteria**: No enterprise policy mechanism exists for origin isolation OR policies cannot be enforced OR users can override enterprise policies OR policy application is inconsistent

**Evidence**: Enterprise policy configuration screenshots, browser policy status page showing applied policies, test results demonstrating policy-based isolation exceptions, diagnostic logs showing policy application

**References**:

- HTML Standard - Origin-keyed agent clusters: https://html.spec.whatwg.org/multipage/origin.html#origin-keyed-agent-clusters
- Site Isolation: https://www.chromium.org/Home/chromium-security/site-isolation/

### Assessment: DOM-REQ-14 (Logging of policy-based isolation exceptions)

**Reference**: DOM-2-REQ-12 - Browser shall log all policy-based isolation exceptions

**Given**: A conformant browser with DOM-2 or higher capability with configured origin isolation policies

**Task**: Verify that the browser logs all policy-based isolation exceptions to provide security teams with visibility into when and where isolation boundaries are relaxed, enabling detection of policy misconfiguration, monitoring of exception usage, and investigation of potential security incidents involving cross-origin access that was permitted through administrative policy rather than standard browser security controls.

**Verification**:

1. Configure enterprise policies that create isolation exceptions for specific origins
2. Access the browser's logging interface (console logs, diagnostic logs, or audit logs)
3. Trigger cross-origin interactions that invoke policy-based exceptions