EN-304-617.md

- **EMB-3-REQ-11**: All native integrations shall be documented and auditable → Assessment: EMB-REQ-46
- **EMB-3-REQ-12**: Enterprise policies shall be able to restrict native integration scope → Assessment: EMB-REQ-47

### 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 → Assessment: EMB-REQ-35
- **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 → Assessment: EMB-REQ-48
- **EMB-0-REQ-8**: All CSP policies shall be strictly enforced without exceptions → Assessment: EMB-REQ-49

#### 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 → Assessment: EMB-REQ-18
- **EMB-1-REQ-12**: Trust allowlist shall be immutable by web content → Assessment: EMB-REQ-50

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

- **EMB-2-REQ-1**: All EMB-1 requirements shall be implemented → Assessment: EMB-REQ-51
- **EMB-2-REQ-2**: Embedded browser shall implement certificate pinning for critical origins → Assessment: EMB-REQ-20
- **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 → Assessment: EMB-REQ-52
- **EMB-2-REQ-9**: Pinning violations shall immediately block content loading → Assessment: EMB-REQ-53
- **EMB-2-REQ-10**: Pin rotation procedures shall be documented and tested → Assessment: EMB-REQ-54

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

- **EMB-3-REQ-1**: Baseline EMB-1 certificate validation shall apply to all remote content → Assessment: EMB-REQ-55
- **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+) → Assessment: EMB-REQ-56
- **EMB-3-REQ-10**: Modified local content shall fail signature verification and be rejected → Assessment: EMB-REQ-57
- **EMB-3-REQ-11**: Signing keys for local content shall be protected from extraction → Assessment: EMB-REQ-58
- **EMB-3-REQ-12**: Hybrid deployments (local + remote) shall maintain strictest security controls for each content type → Assessment: EMB-REQ-59

**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


## 5.9 Remote Data Processing Systems

**[RDPS]** The manufacturer shall implement secure remote data processing systems that protect data confidentiality, integrity, and availability while maintaining product functionality.

**Overview**:

A remote data processing solution (RDPS) is a component of a product that has an essential role in one or more of a product's functions and performs that role remotely from the local components of the product. While many product update methods may fit into the definition of an RDPS, product update requirements are considered separately in Section 5.5 Update Delivery Mechanisms of this document.

All remote data processing solutions are components of the product, but their use is independent of the product's deployment environment. While a product's employment of an RDPS may create additional security requirements related to its remote nature and affect the tools available to an assessor, use of an RDPS does not significantly change the security requirements associated with the product's use or functions.

A remote data processing solution is a component of the product when it has been designed by or for the manufacturer or is in the manufacturer's control, and it is necessary for the product to perform its intended functions. Remote data processing solutions can perform any function of the product and are not limited to a product's core functions. Common uses of RDPS include remote storage of profile or configuration data, often to enable similar devices to use or access the data from a web interface. The system can also be a log storage or metrics collection endpoint, which is part of the product design, but those have dedicated sections in the present document with detailed requirements.

**CRA Applicability**: The CRA has a subtle difference in how the application is designed. A website that is accessed with a browser is not in scope, but an online service which is used from an installed application is in scope. The CRA Article 3(2) defines that an RDPS is under the responsibility of the manufacturer. Therefore, if the product default configuration is overwritten with local amendments by the user of the product, it is important that similar protection can be achieved as described in this section.

**Capability**: Secure remote data processing with encryption, authentication, availability controls, and data protection

**Conditions**:

- **RDPS-0**: No remote data processing (fully local operation)
- **RDPS-1**: Limited remote processing for non-sensitive data (configuration, preferences)
- **RDPS-2**: Extended remote processing including sensitive data with strong security controls
- **RDPS-3**: Full remote processing with critical data requiring maximum security

**Threats**:

- Eavesdropping and man-in-the-middle attacks during data transmission
- Unauthorized access to remote systems and data
- Data integrity compromise and unauthorized modification
- Denial of service attacks affecting service availability
- Multitenant data leakage in shared infrastructure
- Insider abuse and unauthorized access by service operators
- Data residency and sovereignty violations
- Insufficient data protection at rest
- Inadequate backup and recovery capabilities
- Vendor lock-in preventing data portability
- Service discontinuation without migration path
- Configuration tampering when user-defined RDPS endpoints allowed

**Risk**: HIGH - Compromised RDPS can lead to data theft, service disruption, privacy violations, and complete product functionality loss

**Requirements**:

#### RDPS-0 Requirements (No remote data processing)

- **RDPS-0-REQ-1**: Browser shall operate fully offline without requiring remote connectivity → Assessment: RDPS-REQ-52
- **RDPS-0-REQ-2**: All user data shall be stored locally without remote synchronization → Assessment: RDPS-REQ-53
- **RDPS-0-REQ-3**: Browser shall not transmit telemetry, diagnostics, or usage data to remote servers → Assessment: RDPS-REQ-54
- **RDPS-0-REQ-4**: Browser shall function without degradation when network connectivity unavailable → Assessment: RDPS-REQ-55
- **RDPS-0-REQ-5**: No remote authentication or authorization services shall be required → Assessment: RDPS-REQ-56
- **RDPS-0-REQ-6**: Browser shall document all local-only operation capabilities and limitations → Assessment: RDPS-REQ-57
- **RDPS-0-REQ-7**: Users shall be informed that no data leaves the local system → Assessment: RDPS-REQ-58

#### RDPS-1 Requirements (Limited remote processing for non-sensitive data)

- **RDPS-1-REQ-1**: Browser shall document product functionality when RDPS connectivity unavailable → Assessment: RDPS-REQ-1
- **RDPS-1-REQ-2**: Browser shall define all data processed or stored in RDPS with data classification → Assessment: RDPS-REQ-2
- **RDPS-1-REQ-3**: Browser shall classify criticality of all RDPS-processed data → Assessment: RDPS-REQ-3
- **RDPS-1-REQ-4**: Browser shall encrypt all data transmissions to RDPS using TLS 1.3 or higher → Assessment: RDPS-REQ-4
- **RDPS-1-REQ-5**: Browser shall authenticate RDPS endpoints using certificate validation → Assessment: RDPS-REQ-5
- **RDPS-1-REQ-6**: Browser shall implement retry mechanisms with exponential backoff for RDPS failures → Assessment: RDPS-REQ-6
- **RDPS-1-REQ-7**: Browser shall cache critical data locally for offline operation → Assessment: RDPS-REQ-7
- **RDPS-1-REQ-8**: Browser shall implement secure authentication for RDPS access → Assessment: RDPS-REQ-8
- **RDPS-1-REQ-9**: Browser shall validate server certificates and enforce certificate pinning for RDPS → Assessment: RDPS-REQ-9
- **RDPS-1-REQ-10**: Browser shall implement timeout controls for RDPS connections → Assessment: RDPS-REQ-10
- **RDPS-1-REQ-11**: Browser shall log RDPS connectivity failures and errors → Assessment: RDPS-REQ-11
- **RDPS-1-REQ-12**: Browser shall gracefully degrade functionality when RDPS unavailable → Assessment: RDPS-REQ-12
- **RDPS-1-REQ-13**: Browser shall not expose sensitive authentication credentials to RDPS → Assessment: RDPS-REQ-13
- **RDPS-1-REQ-14**: Browser shall implement rate limiting for RDPS requests → Assessment: RDPS-REQ-14
- **RDPS-1-REQ-15**: Browser shall validate all data received from RDPS before processing → Assessment: RDPS-REQ-15

#### RDPS-2 Requirements (Extended remote processing with sensitive data)

- **RDPS-2-REQ-1**: All RDPS-1 requirements shall be implemented → Assessment: RDPS-REQ-59
- **RDPS-2-REQ-2**: Browser shall encrypt sensitive data at rest in RDPS storage → Assessment: RDPS-REQ-16
- **RDPS-2-REQ-3**: Browser shall implement mutual TLS authentication for RDPS connections → Assessment: RDPS-REQ-17
- **RDPS-2-REQ-4**: Browser shall maintain redundant copies of critical data for recovery → Assessment: RDPS-REQ-18
- **RDPS-2-REQ-5**: Browser shall support data recovery from backups with integrity verification → Assessment: RDPS-REQ-19
- **RDPS-2-REQ-6**: Browser shall implement data retention policies with secure deletion → Assessment: RDPS-REQ-20
- **RDPS-2-REQ-7**: Browser shall enforce access controls on RDPS data per-user and per-origin → Assessment: RDPS-REQ-21
- **RDPS-2-REQ-8**: Browser shall audit all RDPS access and modifications → Assessment: RDPS-REQ-22
- **RDPS-2-REQ-9**: Browser shall implement data integrity verification using cryptographic hashes → Assessment: RDPS-REQ-23
- **RDPS-2-REQ-10**: Browser shall protect against RDPS endpoint substitution attacks → Assessment: RDPS-REQ-24
- **RDPS-2-REQ-11**: Browser shall implement defense against replay attacks on RDPS communications → Assessment: RDPS-REQ-25
- **RDPS-2-REQ-12**: Browser shall enforce data minimization principles for RDPS transmissions → Assessment: RDPS-REQ-26
- **RDPS-2-REQ-13**: Browser shall provide user controls for RDPS data synchronization → Assessment: RDPS-REQ-27
- **RDPS-2-REQ-14**: Browser shall implement secure data export from RDPS for data portability → Assessment: RDPS-REQ-28
- **RDPS-2-REQ-15**: When user-configurable RDPS endpoints provided, all associated security settings shall be configurable → Assessment: RDPS-REQ-29
- **RDPS-2-REQ-16**: Browser shall verify RDPS service availability before critical operations → Assessment: RDPS-REQ-30
- **RDPS-2-REQ-17**: Browser shall implement connection pooling with security controls for RDPS → Assessment: RDPS-REQ-31
- **RDPS-2-REQ-18**: Browser shall protect RDPS authentication tokens from extraction and theft → Assessment: RDPS-REQ-32

#### RDPS-3 Requirements (Full remote processing with critical data)

- **RDPS-3-REQ-1**: All RDPS-2 requirements shall be implemented → Assessment: RDPS-REQ-60
- **RDPS-3-REQ-2**: Browser shall implement end-to-end encryption for all critical data in RDPS → Assessment: RDPS-REQ-33
- **RDPS-3-REQ-3**: Browser shall use hardware-backed key storage for RDPS encryption keys → Assessment: RDPS-REQ-34
- **RDPS-3-REQ-4**: Browser shall implement high-availability RDPS architecture with failover → Assessment: RDPS-REQ-35
- **RDPS-3-REQ-5**: Browser shall document and test RDPS disaster recovery procedures → Assessment: RDPS-REQ-36
- **RDPS-3-REQ-6**: Browser shall implement real-time RDPS integrity monitoring → Assessment: RDPS-REQ-37
- **RDPS-3-REQ-7**: Browser shall provide RDPS security event logging with SIEM integration → Assessment: RDPS-REQ-38
- **RDPS-3-REQ-8**: Browser shall enforce geographic data residency requirements when configured → Assessment: RDPS-REQ-39
- **RDPS-3-REQ-9**: Browser shall implement zero-trust architecture for RDPS access → Assessment: RDPS-REQ-40
- **RDPS-3-REQ-10**: Browser shall support regulatory compliance logging for RDPS operations → Assessment: RDPS-REQ-41
- **RDPS-3-REQ-11**: Browser shall implement automated RDPS security scanning and vulnerability detection → Assessment: RDPS-REQ-42
- **RDPS-3-REQ-12**: Browser shall provide cryptographic proof of RDPS data integrity → Assessment: RDPS-REQ-43
- **RDPS-3-REQ-13**: Browser shall implement secure multi-tenancy with data isolation in RDPS → Assessment: RDPS-REQ-44
- **RDPS-3-REQ-14**: Browser shall provide incident response procedures for RDPS breaches → Assessment: RDPS-REQ-45
- **RDPS-3-REQ-15**: Browser shall implement RDPS access revocation mechanisms → Assessment: RDPS-REQ-46
- **RDPS-3-REQ-16**: Browser shall provide transparency reporting for RDPS data access → Assessment: RDPS-REQ-47
- **RDPS-3-REQ-17**: Browser shall implement forward secrecy for RDPS communications → Assessment: RDPS-REQ-48
- **RDPS-3-REQ-18**: Browser shall provide user notification of RDPS security events → Assessment: RDPS-REQ-49
- **RDPS-3-REQ-19**: Browser shall document service discontinuation and data migration procedures → Assessment: RDPS-REQ-50
- **RDPS-3-REQ-20**: Enterprise administrators shall be able to configure RDPS security policies → Assessment: RDPS-REQ-51


# 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 → Create cross-origin iframes (example.com embedding test.com) and verify they run in separate processes
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) → Confirm that each distinct site (eTLD+1) is allocated a separate renderer process
3. Identify the renderer processes associated with each origin → Verify that same-site navigations reuse the same renderer process
4. Record the Process IDs (PIDs) for each origin's renderer process → Check that cross-origin iframes are isolated in separate processes from their embedder
5. Navigate from https://example.com to https://example.com/page2 and verify the PID remains the same → Validate that process separation is maintained throughout the browser session
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 → 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) → Test edge cases: nosniff headers, ambiguous MIME types, empty responses
2. Create a test page at https://attacker.com that attempts to load resources from https://victim.com using various methods: → Confirm that JSON, HTML, and XML responses without CORS headers are blocked from cross-origin script contexts
   - `<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 → Verify that browser console shows CORB warning messages with details of blocked resources
4. Monitor network traffic using browser DevTools to capture CORB decisions → Check that network panel shows resources blocked with CORB designation
5. Verify that cross-origin requests for JSON/HTML/XML are blocked when served with incorrect MIME types → Validate that legitimate cross-origin subresources (images, scripts with correct MIME types) load successfully
6. Verify that legitimate cross-origin image/script/CSS loads still succeed → 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 → Verify that `Location` object allows limited cross-origin access (href setter only) but not href getter
2. From site-a, open site-b in a new window using `window.open()` → Confirm that all cross-origin DOM access attempts throw SecurityError exceptions
3. Attempt cross-origin DOM access from site-a to site-b window: → Verify that browser console logs SecurityError with clear origin mismatch messages
   - `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 → Check that same-origin window access succeeds without errors
5. Test that same-origin window access succeeds → Validate that postMessage() works correctly for cross-origin communication
6. Test `window.postMessage()` as the legitimate cross-origin communication channel → 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 → Test preflight caching behavior
2. Create test pages that make various fetch() requests to cross-origin servers: → Confirm that OPTIONS preflight requests are sent before all non-simple cross-origin requests
   - 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 → Verify that actual requests only proceed after successful preflight response with matching CORS headers
4. Configure the server to respond with various CORS header combinations: → Check that browser blocks requests when preflight fails or returns incorrect headers
   - 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 → Validate that preflight responses are cached according to Access-Control-Max-Age

**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 → Verify that SameSite=None requires Secure attribute
2. Configure site-a to set cookies with various SameSite attributes: → Confirm that SameSite=Strict cookies are never sent in cross-site contexts
   - `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: → Verify that SameSite=Lax cookies are sent only in top-level navigation (GET)
   - 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 → Check that SameSite=None cookies are sent in all contexts but require Secure attribute
5. Test the default SameSite behavior for cookies without explicit attribute (should be Lax) → Validate that cookies without SameSite attribute default to Lax behavior

**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 → Test port isolation (example.com:443 vs example.com:8080)
2. In each origin, write distinct data to localStorage: → Clear storage for one origin and verify other origins' storage is unaffected
   ```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 → Confirm that each origin has completely isolated localStorage namespace
4. Attempt to read localStorage and IndexedDB from each origin → Verify that each origin has completely isolated IndexedDB namespace
5. Verify that each origin only sees its own storage → Check that different subdomains cannot access each other's storage
6. Test subdomain isolation (example.com vs sub.example.com) → Validate that different protocols (http vs https) have separate storage
7. Test protocol isolation (https vs http) → Confirm that different ports have separate storage

**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: → Confirm that sandbox attribute restricts capabilities according to specified tokens
   ```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: → Verify that scripts are blocked unless allow-scripts is present
   - 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 → Check that same-origin access is blocked unless allow-same-origin is present
4. Test that sandbox="" (empty) applies strictest restrictions → Validate that sandboxed frames without allow-same-origin have unique opaque origin
5. Test CSP sandbox directive equivalence → Confirm that browser console logs security errors for blocked actions
6. Verify unique origin treatment for sandboxed iframes without allow-same-origin → 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) → Test CORP enforcement in cross-origin isolated contexts (COOP+COEP)
2. Configure site-a to serve resources with various CORP headers: → Confirm that resources with CORP: same-origin are blocked from cross-origin loads
   - `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: → Verify that resources with CORP: same-site are blocked from cross-site loads but allowed same-site
   ```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 → Check that resources with CORP: cross-origin load from any origin
5. Test CORP interaction with CORS headers → Validate that browser console shows CORP blocking errors with clear messages
6. Verify that CORP applies to all resource types (images, scripts, frames, fetch) → Confirm that CORP is enforced for all resource types

**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: → Test COOP reporting endpoint functionality
   - `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: → Confirm that COOP: same-origin severs opener relationship with cross-origin pages
   - 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 → Verify that COOP: same-origin-allow-popups preserves opener for popups but not navigations
4. Test that cross-origin-isolated pages cannot be in the same browsing context group as non-isolated pages → Check that cross-origin isolated pages (COOP + COEP) get access to high-resolution timers and SharedArrayBuffer
5. Verify SharedArrayBuffer availability in cross-origin isolated contexts → Validate that browser process allocation reflects browsing context group isolation

**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` → Confirm that resources without CORP or CORS are blocked when page has COEP: require-corp
2. From this page, attempt to load various cross-origin resources: → Verify that resources with CORP: cross-origin load successfully
   - 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 → Check that resources with CORS and crossorigin attribute load successfully
4. Test COEP: credentialless as alternative to require-corp → Validate that iframes without COEP are blocked from embedding in COEP page
5. Verify that combining COOP + COEP enables cross-origin isolation → Confirm that browser console shows COEP blocking errors
6. Test COEP violation reporting → 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 → Test browser console warnings about document.domain deprecation
2. Attempt to relax same-origin policy using document.domain: → Confirm that document.domain setter is unavailable or no-op by default
   ```javascript
   // On both sub1.example.com and sub2.example.com
   document.domain = 'example.com';
   ```
3. Verify that document.domain setter is either: → Verify that pages can only set document.domain if they explicitly opt-out via Origin-Agent-Cluster: ?0
   - 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 → Check that browser console shows deprecation warnings when document.domain is accessed
5. Verify that failing to set document.domain prevents cross-subdomain DOM access → Validate that cross-subdomain access fails when document.domain is disabled

**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 → Verify that origins not covered by the policy maintain default isolation
2. Identify available policies related to origin isolation (e.g., SitePerProcessMode, IsolateOriginsMode, CrossOriginPolicyExceptions) → Test that policy changes require browser restart or profile reload to take effect
3. Configure a policy to modify default isolation behavior for specific origins or domains → Confirm that policy-configured exceptions are logged in browser diagnostic logs
4. Deploy the policy through enterprise management tools (Group Policy, MDM, configuration management) → Verify that users cannot override enterprise-configured isolation policies
5. Verify that the browser applies the configured policy on startup → Test that malformed policies are rejected with clear error messages
6. Test that the configured isolation exceptions work as intended for specified origins → 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 → Test that log entries distinguish between policy-based exceptions and standard CORS/postMessage
2. Access the browser's logging interface (console logs, diagnostic logs, or audit logs) → Verify that logs can be exported or forwarded to SIEM systems
3. Trigger cross-origin interactions that invoke policy-based exceptions → Confirm that logging does not expose sensitive user data
4. Verify that each exception usage is logged with relevant details: → Test that log volume is reasonable and does not impact browser performance
   - Timestamp of the exception
   - Source and target origins involved
   - Policy name or identifier that permitted the exception
   - Type of isolation relaxation (storage access, DOM access, etc.)
5. Test that logs include sufficient information for security auditing → Verify that logs persist across browser restarts
6. Verify that logs are written to a location accessible to security teams → Validate that disabled logging can be detected by monitoring systems

**Pass Criteria**: All policy-based isolation exceptions are logged AND logs contain sufficient detail for auditing AND logs are accessible to security teams AND logging does not expose sensitive data

**Fail Criteria**: Isolation exceptions are not logged OR logs lack necessary detail OR logs are inaccessible OR logging exposes sensitive user information

**Evidence**: Log file excerpts showing isolation exception entries, log analysis demonstrating completeness, SIEM integration test results, documentation of log format and fields

**References**:

- CWE-778: Insufficient Logging: https://cwe.mitre.org/data/definitions/778.html
- OWASP Logging Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html

### Assessment: DOM-REQ-15 (Compatibility mode isolation integrity)

**Reference**: DOM-3-REQ-7 - Compatibility modes shall not weaken core isolation boundaries

**Given**: A conformant browser with DOM-3 capability and compatibility modes enabled

**Task**: Verify that browser compatibility modes designed to support legacy web content do not compromise fundamental origin isolation boundaries, ensuring that even when compatibility features are enabled for older sites or applications, core security mechanisms like process isolation, storage separation, and cross-origin restrictions remain effective, preventing compatibility modes from becoming vectors for cross-origin attacks.

**Verification**:

1. Identify available compatibility modes in the browser (e.g., quirks mode, document mode, legacy rendering mode) → Test that CORS and SameSite policies are enforced in compatibility mode
2. Enable compatibility mode through meta tags, HTTP headers, or browser settings → Verify that sandbox attributes on iframes work correctly in compatibility mode
3. Load test pages with compatibility mode activated → Test that postMessage remains the only valid cross-origin communication mechanism
4. Verify that process-per-site isolation remains active under compatibility mode → Confirm that compatibility mode does not bypass Content Security Policy
5. Test that storage (localStorage, sessionStorage, IndexedDB) remains origin-isolated in compatibility mode → Verify that cross-origin cookies are still subject to SameSite restrictions
6. Attempt cross-origin DOM access in compatibility mode and verify it is blocked → Test that compatibility mode does not enable deprecated features like unrestricted document.domain

**Pass Criteria**: Core isolation mechanisms remain enforced in compatibility mode AND process isolation is maintained AND storage isolation is preserved AND cross-origin restrictions are not weakened

**Fail Criteria**: Compatibility mode weakens any core isolation boundary OR enables cross-origin access not available in standard mode OR bypasses security policies

**Evidence**: Test results demonstrating isolation enforcement in compatibility mode, process inspection showing maintained process separation, DevTools showing storage isolation, security policy enforcement verification

**References**:

- HTML Standard - Quirks mode: https://html.spec.whatwg.org/multipage/dom.html#concept-document-quirks
- Same-origin policy: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

### Assessment: DOM-REQ-16 (Third-party integration isolation)

**Reference**: DOM-3-REQ-8 - Third-party integrations shall be subject to same origin isolation policies

**Given**: A conformant browser with DOM-3 capability supporting third-party integrations

**Task**: Verify that third-party browser integrations such as plugins, extensions, or embedded components are subject to the same origin isolation policies as standard web content, preventing privileged integrations from bypassing security boundaries to access cross-origin data, ensuring that even trusted third-party code operates within the browser's security model and cannot be exploited to violate origin isolation.

**Verification**:

1. Install or enable third-party integrations (extensions, plugins, or native components) → Verify that third-party integrations run in appropriately isolated processes
2. Load web content from multiple origins (https://example.com, https://test.com) → Test that integration code injected into pages respects Content Security Policy
3. Verify that third-party integrations cannot access cross-origin DOM without proper permissions → Confirm that integrations cannot bypass SameSite cookie restrictions
4. Test that third-party code cannot read localStorage or cookies from other origins → Verify that third-party code cannot relax origin isolation through internal APIs
5. Verify that integrations requiring cross-origin access declare explicit permissions → Test that integration crashes or failures do not compromise other origins
6. Test that integration-provided APIs are subject to CORS when accessed cross-origin → Validate that integration permissions are clearly disclosed to users

**Pass Criteria**: Third-party integrations are subject to origin isolation AND cannot bypass cross-origin restrictions AND require explicit permissions for cross-origin access AND run in isolated contexts

**Fail Criteria**: Third-party integrations can bypass origin isolation OR access cross-origin data without permissions OR are not properly isolated

**Evidence**: Integration security test results, permission disclosure screenshots, process isolation verification, cross-origin access attempt logs showing blocks

**References**:

- Web Extensions API: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions
- Same-origin policy: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

### Assessment: DOM-REQ-17 (Documentation and logging of compatibility exceptions)

**Reference**: DOM-3-REQ-9 - All isolation exceptions for compatibility shall be documented and logged

**Given**: A conformant browser with DOM-3 capability with compatibility-related isolation exceptions

**Task**: Verify that all isolation exceptions implemented for compatibility reasons are comprehensively documented for developers and administrators, and that runtime usage of these exceptions is logged for security monitoring, ensuring transparency about when and why isolation boundaries are relaxed and enabling detection of unexpected or malicious use of compatibility features to bypass security controls.

**Verification**:

1. Review browser documentation for a complete list of compatibility-related isolation exceptions
2. Verify that each exception is documented with:
   - Clear description of the exception behavior
   - Justification for why the exception exists
   - Affected origins or scenarios
   - Security implications and mitigations
   - Deprecation timeline (if applicable)
3. Enable browser diagnostic logging or audit logging
4. Trigger compatibility features that involve isolation exceptions
5. Verify that each exception usage is logged in real-time with:
   - Timestamp of exception invocation
   - Origin(s) involved
   - Type of isolation exception (e.g., cross-origin storage access, DOM access)
   - Compatibility feature that triggered the exception
6. Test that logs include context for security analysis
7. Verify that logs can be reviewed by security teams
8. Confirm that exception documentation is accessible to web developers
9. Test that undocumented exceptions are flagged as potential issues
10. Validate that log entries are distinct from standard CORS/postMessage usage

**Pass Criteria**: All compatibility exceptions are documented AND documentation includes security implications AND runtime usage is logged AND logs provide sufficient detail for security analysis

**Fail Criteria**: Exceptions are undocumented OR documentation lacks security details OR exception usage is not logged OR logs are insufficient for analysis

**Evidence**: Documentation excerpts describing exceptions, log samples showing exception usage, security team access verification, developer documentation review

**References**:

- CWE-778: Insufficient Logging: https://cwe.mitre.org/data/definitions/778.html
- OWASP Application Security Verification Standard: https://owasp.org/www-project-application-security-verification-standard/

### Assessment: DOM-REQ-18 (Embedded component storage isolation)

**Reference**: DOM-3-REQ-10 - Embedded components shall maintain storage isolation from embedding context

**Given**: A conformant browser with DOM-3 capability supporting embedded browser components

**Task**: Verify that embedded browser components (such as WebView controls in native applications or embedded iframes) maintain strict storage isolation from their embedding context, preventing the embedding application or parent frame from directly accessing the embedded component's localStorage, cookies, IndexedDB, or other origin-scoped storage, ensuring that embedded web content cannot be compromised through storage manipulation by the host application.

**Verification**:

1. Create an embedded browser component (WebView, iframe) in a host application or page → Test that the embedded component cannot access the embedding application's storage
2. Load web content in the embedded component from origin https://example.com → Verify that storage isolation is maintained even if origins match
3. From the embedding context, attempt to access the embedded component's storage: → Test that only secure message-passing APIs can exchange data between contexts
   - Try to read localStorage from the embedded origin
   - Attempt to access cookies belonging to the embedded origin
   - Try to open IndexedDB databases from the embedded origin
4. Verify that all direct storage access attempts from embedding context are blocked → Confirm that clearing embedding context storage does not affect embedded component storage
5. Load the same origin (https://example.com) in a separate tab or window → Verify that embedded component storage persists independently
6. Verify that storage is isolated between embedded component and separate browsing context → Test that storage isolation applies to all storage mechanisms (localStorage, sessionStorage, IndexedDB, Cache API, cookies)

**Pass Criteria**: Embedded components maintain complete storage isolation AND embedding context cannot access embedded storage AND only secure APIs enable data exchange AND isolation applies to all storage types

**Fail Criteria**: Embedding context can access embedded component storage OR storage isolation is incomplete OR isolation can be bypassed

**Evidence**: Test results showing blocked storage access attempts, storage isolation verification across contexts, secure API usage examples, developer documentation of isolation boundaries

**References**:

- Web Storage API: https://html.spec.whatwg.org/multipage/webstorage.html
- IndexedDB API: https://w3c.github.io/IndexedDB/
- Cookies: https://httpwg.org/specs/rfc6265.html

## 6.2 Extension System Security Assessments

This section covers assessment procedures for requirements EXT-REQ-1 through EXT-REQ-18, addressing browser extension security including permissions, content script isolation, extension API access control, manifest validation, and extension update security.

### Assessment: EXT-REQ-1 (Permission model for extensions)

**Reference**: EXT-REQ-1 - Browser shall implement a permission model that restricts extension capabilities to explicitly declared permissions

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

**Task**: Verify that the browser implements a least-privilege permission model for extensions to prevent malicious or compromised extensions from accessing sensitive APIs and user data beyond their declared functionality, protecting users from over-privileged extensions that could steal credentials, intercept network traffic, or exfiltrate browsing history without explicit user consent.

**Verification**:

1. Create a test extension with a minimal manifest.json declaring only basic permissions (e.g., "storage", "tabs") → Verify that extensions cannot dynamically request permissions not declared in optional_permissions
2. Attempt to use APIs that require undeclared permissions: → Test that host permissions are enforced for content script injection and webRequest interception
   - Cookie management interface (requires "cookies" permission)
   - Network request interception interface (requires "webRequest" permission)
   - File download interface (requires "downloads" permission)
   - Access to specific host patterns not declared in host_permissions
3. Verify that the browser blocks API access and throws exceptions for undeclared permissions → Confirm that extensions cannot access APIs without corresponding manifest permissions
4. Monitor browser console for permission-related error messages → Verify that browser throws clear error messages when undeclared APIs are accessed (e.g., "Cannot access cookie management interface without 'cookies' permission")
5. Add the required permissions to manifest.json and reload the extension → Check that permission prompts at install time accurately reflect all requested permissions
6. Verify that previously blocked APIs now function correctly → Validate that host permissions restrict content script injection to declared patterns
7. Test that permission requests at install time accurately reflect manifest declarations → Confirm that optional permissions can only be requested if declared in manifest

**Pass Criteria**: All API access is blocked when permissions are not declared AND clear error messages are shown AND permission grants are persistent across sessions

**Fail Criteria**: Any API access succeeds without declared permission OR permission system can be bypassed OR no error messages are shown

**Evidence**: Console screenshots showing permission errors, test results demonstrating API blocking, DevTools Extension panel showing active permissions, permission prompt screenshots

**References**:

- Chrome Extension Permissions: https://developer.chrome.com/docs/extensions/mv3/declare_permissions/
- Mozilla WebExtensions Permissions: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions
- Manifest V3 Permissions: https://developer.chrome.com/docs/extensions/mv3/permission_warnings/
- CWE-250: Execution with Unnecessary Privileges: https://cwe.mitre.org/data/definitions/250.html
- Optional Permissions API: https://developer.chrome.com/docs/extensions/reference/permissions/
- WebExtensions Security Best Practices: https://extensionworkshop.com/documentation/develop/build-a-secure-extension/

### Assessment: EXT-REQ-2 (Content script isolation)

**Reference**: EXT-REQ-2 - Browser shall isolate content scripts from web page JavaScript contexts

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

**Task**: Verify that the browser isolates content scripts in a separate JavaScript execution world from the host web page to prevent malicious pages from stealing extension secrets, intercepting extension message passing, or using prototype pollution to compromise the extension's security, while allowing content scripts to safely manipulate the DOM for legitimate functionality.

**Verification**:

1. Create a test extension with a content script that: → Test protection against prototype pollution attacks from page context to content script
   - Defines a global variable: `var extensionSecret = "sensitive_data"`
   - Attempts to access variables defined by the web page
   - Uses messaging to communicate with the background script
2. Create a test web page that: → Confirm that content scripts and web page JavaScript execute in separate JavaScript worlds
   - Defines its own global variables: `var pageVariable = "page_data"`
   - Attempts to access variables defined by the content script
   - Attempts to intercept or modify content script message passing
3. Verify that the content script cannot directly access web page variables and vice versa → Verify that variables and functions defined in one context are not accessible from the other
4. Test that content scripts run in an isolated JavaScript world with separate global scope → Check that content scripts can manipulate the DOM but cannot access JavaScript objects from page context
5. Verify that DOM modifications are visible to both contexts but JavaScript objects are not shared → Validate that message passing between content scripts and extension background is not interceptable by web page
6. Test that the web page cannot intercept extension runtime message passing calls from content scripts → Confirm that prototype modifications in page context do not affect content script execution
7. Verify that content scripts cannot access page's inline event handlers or Function.prototype modifications → Verify that content scripts have access to clean browser APIs unmodified by page JavaScript

**Pass Criteria**: Complete JavaScript isolation between content script and web page contexts AND secure message passing AND protection from prototype pollution

**Fail Criteria**: Any JavaScript objects/variables leak between contexts OR message passing can be intercepted OR prototype pollution succeeds

**Evidence**: Console logs showing undefined variables across contexts, test results demonstrating isolation, browser DevTools showing separate execution contexts, security test results showing prototype pollution protection

**References**:

- Chrome Content Script Isolated Worlds: https://developer.chrome.com/docs/extensions/mv3/content_scripts/#isolated_world
- Mozilla Content Script Execution Environment: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts#execution_environment
- WebExtensions Content Script Security: https://developer.chrome.com/docs/extensions/mv3/security/
- CWE-501: Trust Boundary Violation: https://cwe.mitre.org/data/definitions/501.html
- Prototype Pollution Prevention: https://portswigger.net/web-security/prototype-pollution
- Content Script Communication: https://developer.chrome.com/docs/extensions/mv3/messaging/

### Assessment: EXT-REQ-3 (Extension API access control)

**Reference**: EXT-REQ-3 - Browser shall enforce access control for sensitive extension APIs based on manifest declarations

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

**Task**: Verify that the browser restricts access to powerful extension APIs (debugger, privacy settings, system information) based on explicit manifest permissions to prevent malicious extensions from escalating privileges, debugging other extensions/tabs to steal data, modifying privacy settings, or accessing system information without user awareness and consent.

**Verification**:

1. Identify sensitive extension APIs that require specific permissions: → Verify access control is enforced consistently across background scripts, content scripts, and popup contexts
   - Debugger interface (requires "debugger" permission)
   - Extension management interface (requires "management" permission)
   - Privacy settings interface (requires "privacy" permission)
   - System information interfaces for CPU/memory/storage (requires "system.*" permissions)
   - Desktop capture interface (requires "desktopCapture" permission)
2. Create test extensions with varying permission sets → Confirm that sensitive APIs are blocked without appropriate permissions
3. Attempt to access each sensitive API without the required permission → Verify that browser throws descriptive errors when API access is denied
4. Verify that access is denied with clear error messages → Check that permission warnings during extension install clearly communicate sensitive capabilities
5. Test that powerful APIs like debugger and management show enhanced warnings during install → Validate that API access control is enforced uniformly across all extension contexts
6. Verify that certain APIs (e.g., debugger) cannot be used in published extensions on official extension stores → Confirm that no bypasses exist through code evaluation or dynamic loading
7. Test that API access control cannot be bypassed through indirect means (eval, dynamic code loading) → Verify that debugger and management APIs show enhanced security warnings

**Pass Criteria**: All sensitive APIs are access-controlled based on manifest permissions AND appropriate warnings are shown AND no bypass mechanisms exist

**Fail Criteria**: Any sensitive API accessible without permission OR warnings are insufficient OR bypass mechanisms exist

**Evidence**: Console screenshots showing API access errors, permission prompt screenshots showing warnings, test results across multiple extension contexts, official extension store policy enforcement verification

**References**:

- Chrome Extension API Reference: https://developer.chrome.com/docs/extensions/reference/
- Sensitive Permissions in Chrome: https://developer.chrome.com/docs/extensions/mv3/permission_warnings/#permissions_with_warnings
- Mozilla WebExtensions API: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API
- Chrome Debugger API Restrictions: https://developer.chrome.com/docs/extensions/reference/debugger/
- CWE-306: Missing Authentication for Critical Function: https://cwe.mitre.org/data/definitions/306.html

### Assessment: EXT-REQ-4 (Manifest validation)

**Reference**: EXT-REQ-4 - Browser shall validate extension manifests and reject extensions with invalid or malicious manifest declarations

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

**Task**: Verify that the browser strictly validates extension manifest files to prevent installation of malformed or malicious extensions that declare invalid permissions, overly broad access patterns, insecure content security policies, or deprecated features, protecting users from extensions that attempt to bypass security controls through manifest manipulation.

**Verification**:

1. Create test extensions with various manifest violations: → Test that manifest changes require extension reload and revalidation
   - Missing required fields (name, version, manifest_version)
   - Invalid JSON syntax
   - Unsupported manifest_version (e.g., manifest_version: 1)
   - Invalid permission names
   - Malformed host_permissions patterns
   - Content security policy violations
   - Invalid web_accessible_resources declarations
2. Attempt to load each malformed extension through the browser's extension management interface in developer mode → Confirm that extensions with invalid manifests are rejected at load time
3. Verify that the browser rejects invalid manifests with clear error messages → Verify that clear, actionable error messages describe manifest violations
4. Test manifest schema validation for all fields (permissions, content_scripts, background, etc.) → Check that manifest schema is strictly enforced for all fields
5. Verify that overly broad host permissions trigger warnings (e.g., <all_urls>, *://*/*) → Validate that overly broad permissions trigger user-visible warnings
6. Test validation of content_security_policy field for Manifest V3 requirements → Confirm that Manifest V3 CSP restrictions are enforced (no unsafe-eval, no remote code)
7. Verify rejection of deprecated Manifest V2 fields in Manifest V3 extensions → Verify that deprecated Manifest V2 features are rejected in Manifest V3

**Pass Criteria**: All manifest violations are detected and rejected AND clear error messages guide developers AND dangerous patterns trigger warnings

**Fail Criteria**: Invalid manifests are accepted OR error messages are unclear OR dangerous patterns have no warnings

**Evidence**: Screenshots of manifest validation errors, test results with various malformed manifests, warning dialogs for broad permissions, browser console logs during extension load

**References**:

- Chrome Manifest File Format: https://developer.chrome.com/docs/extensions/mv3/manifest/
- Manifest V3 Migration Guide: https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/
- Mozilla Manifest.json Documentation: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json
- Extension Content Security Policy: https://developer.chrome.com/docs/extensions/mv3/manifest/content_security_policy/
- CWE-20: Improper Input Validation: https://cwe.mitre.org/data/definitions/20.html
- WebExtensions Manifest Validation: https://extensionworkshop.com/documentation/develop/manifest-v3-migration-guide/

### Assessment: EXT-REQ-5 (Extension sandboxing)

**Reference**: EXT-REQ-5 - Browser shall sandbox extension processes to prevent system-level access and privilege escalation

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

**Task**: Verify that the browser runs extension processes in an operating system sandbox with reduced privileges to prevent malicious extensions from accessing the file system directly, executing arbitrary system commands, creating processes, or escalating privileges to compromise the user's system, limiting extensions to controlled APIs and native messaging for necessary system interactions.

**Verification**:

1. Load a test extension and identify its background service worker process using browser task manager or process explorer → Confirm that extension processes run in a restricted sandbox with limited system access
2. Attempt to execute operations that require system-level privileges from the extension: → Verify that direct file system access outside storage APIs is blocked
   - File system access outside of extension storage APIs