EN-304-617.md.backup

- 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


#### 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
- **RDPS-0-REQ-2**: All user data shall be stored locally without remote synchronization
- **RDPS-0-REQ-3**: Browser shall not transmit telemetry, diagnostics, or usage data to remote servers
- **RDPS-0-REQ-4**: Browser shall function without degradation when network connectivity unavailable
- **RDPS-0-REQ-5**: No remote authentication or authorization services shall be required
- **RDPS-0-REQ-6**: Browser shall document all local-only operation capabilities and limitations
- **RDPS-0-REQ-7**: Users shall be informed that no data leaves the local system

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

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

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

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

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

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


# 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
4. Verify that each exception usage is logged with relevant details:
   - 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
6. Verify that logs are written to a location accessible to security teams
7. Test that log entries distinguish between policy-based exceptions and standard CORS/postMessage
8. Verify that logs can be exported or forwarded to SIEM systems
9. Confirm that logging does not expose sensitive user data
10. Test that log volume is reasonable and does not impact browser performance
11. Verify that logs persist across browser restarts
12. 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)
2. Enable compatibility mode through meta tags, HTTP headers, or browser settings
3. Load test pages with compatibility mode activated
4. Verify that process-per-site isolation remains active under compatibility mode
5. Test that storage (localStorage, sessionStorage, IndexedDB) remains origin-isolated in compatibility mode
6. Attempt cross-origin DOM access in compatibility mode and verify it is blocked
7. Test that CORS and SameSite policies are enforced in compatibility mode
8. Verify that sandbox attributes on iframes work correctly in compatibility mode
9. Test that postMessage remains the only valid cross-origin communication mechanism
10. Confirm that compatibility mode does not bypass Content Security Policy
11. Verify that cross-origin cookies are still subject to SameSite restrictions
12. 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)
2. Load web content from multiple origins (https://example.com, https://test.com)
3. Verify that third-party integrations cannot access cross-origin DOM without proper permissions
4. Test that third-party code cannot read localStorage or cookies from other origins
5. Verify that integrations requiring cross-origin access declare explicit permissions
6. Test that integration-provided APIs are subject to CORS when accessed cross-origin
7. Verify that third-party integrations run in appropriately isolated processes
8. Test that integration code injected into pages respects Content Security Policy
9. Confirm that integrations cannot bypass SameSite cookie restrictions
10. Verify that third-party code cannot relax origin isolation through internal APIs
11. Test that integration crashes or failures do not compromise other origins
12. 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
2. Load web content in the embedded component from origin https://example.com
3. From the embedding context, attempt to access the embedded component's storage:
   - 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
5. Load the same origin (https://example.com) in a separate tab or window
6. Verify that storage is isolated between embedded component and separate browsing context
7. Test that the embedded component cannot access the embedding application's storage
8. Verify that storage isolation is maintained even if origins match
9. Test that only secure message-passing APIs can exchange data between contexts
10. Confirm that clearing embedding context storage does not affect embedded component storage
11. Verify that embedded component storage persists independently
12. 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")
2. Attempt to use APIs that require undeclared permissions:
   - 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
4. Monitor browser console for permission-related error messages
5. Add the required permissions to manifest.json and reload the extension
6. Verify that previously blocked APIs now function correctly
7. Test that permission requests at install time accurately reflect manifest declarations
8. Verify that extensions cannot dynamically request permissions not declared in optional_permissions
9. Test that host permissions are enforced for content script injection and webRequest interception
10. Confirm that extensions cannot access APIs without corresponding manifest permissions
11. Verify that browser throws clear error messages when undeclared APIs are accessed (e.g., "Cannot access cookie management interface without 'cookies' permission")
12. Check that permission prompts at install time accurately reflect all requested permissions
13. Validate that host permissions restrict content script injection to declared patterns
14. Confirm that optional permissions can only be requested if declared in manifest
15. Verify that runtime permission requests are properly gated by manifest declarations

**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:
   - 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:
   - 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
4. Test that content scripts run in an isolated JavaScript world with separate global scope
5. Verify that DOM modifications are visible to both contexts but JavaScript objects are not shared
6. Test that the web page cannot intercept extension runtime message passing calls from content scripts
7. Verify that content scripts cannot access page's inline event handlers or Function.prototype modifications
8. Test protection against prototype pollution attacks from page context to content script
9. Confirm that content scripts and web page JavaScript execute in separate JavaScript worlds
10. Verify that variables and functions defined in one context are not accessible from the other
11. Check that content scripts can manipulate the DOM but cannot access JavaScript objects from page context
12. Validate that message passing between content scripts and extension background is not interceptable by web page
13. Confirm that prototype modifications in page context do not affect content script execution
14. 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