EN-304-617.md

- **EMB-3-REQ-7**: DNS rebinding prevention shall be enforced → Assessment: EMB-REQ-31
- **EMB-3-REQ-8**: Trust boundary violations shall trigger detailed security events → Assessment: EMB-REQ-32
- **EMB-3-REQ-9**: Local content signature verification shall use secure algorithms (RSA-2048+, ECDSA P-256+)
- **EMB-3-REQ-10**: Modified local content shall fail signature verification and be rejected
- **EMB-3-REQ-11**: Signing keys for local content shall be protected from extraction
- **EMB-3-REQ-12**: Hybrid deployments (local + remote) shall maintain strictest security controls for each content type

**References**:

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

# 6 Technical Security Assessments

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

## 6.1 Domain and Origin Isolation Assessments

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

## 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:
   - chrome.cookies API (requires "cookies" permission)
   - chrome.webRequest API (requires "webRequest" permission)
   - chrome.downloads API (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 chrome.cookies 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 chrome.runtime.sendMessage() 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
- 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:
   - chrome.debugger (requires "debugger" permission)
   - chrome.management (requires "management" permission)
   - chrome.privacy (requires "privacy" permission)
   - chrome.system.cpu/memory/storage (requires "system.*" permissions)
   - chrome.desktopCapture (requires "desktopCapture" permission)
2. Create test extensions with varying permission sets
3. Attempt to access each sensitive API without the required permission
4. Verify that access is denied with clear error messages
5. Test that powerful APIs like debugger and management show enhanced warnings during install
6. Verify that certain APIs (e.g., debugger) cannot be used in published extensions on Chrome Web Store
7. Test that API access control cannot be bypassed through indirect means (eval, dynamic code loading)
8. Verify access control is enforced consistently across background scripts, content scripts, and popup contexts
9. Confirm that sensitive APIs are blocked without appropriate permissions
10. Verify that browser throws descriptive errors when API access is denied
11. Check that permission warnings during extension install clearly communicate sensitive capabilities
12. Validate that API access control is enforced uniformly across all extension contexts
13. Confirm that no bypasses exist through code evaluation or dynamic loading
14. 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, Chrome Web 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:
   - 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 chrome://extensions in developer mode
3. Verify that the browser rejects invalid manifests with clear error messages
4. Test manifest schema validation for all fields (permissions, content_scripts, background, etc.)
5. Verify that overly broad host permissions trigger warnings (e.g., <all_urls>, *://*/*)
6. Test validation of content_security_policy field for Manifest V3 requirements
7. Verify rejection of deprecated Manifest V2 fields in Manifest V3 extensions
8. Test that manifest changes require extension reload and revalidation
9. Confirm that extensions with invalid manifests are rejected at load time
10. Verify that clear, actionable error messages describe manifest violations
11. Check that manifest schema is strictly enforced for all fields
12. Validate that overly broad permissions trigger user-visible warnings
13. Confirm that Manifest V3 CSP restrictions are enforced (no unsafe-eval, no remote code)
14. Verify that deprecated Manifest V2 features are rejected in Manifest V3
15. Check that manifest validation occurs on every extension load/reload

**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
2. Attempt to execute operations that require system-level privileges from the extension:
   - File system access outside of extension storage APIs
   - Network operations outside of allowed extension APIs
   - Process creation or system command execution
   - Access to other processes' memory
3. Use platform-specific tools to verify sandbox restrictions:
   - Windows: Process Explorer to check process token and integrity level
   - macOS: Activity Monitor and sandbox-exec to check sandbox profile
   - Linux: /proc filesystem and seccomp to verify syscall restrictions
4. Verify that extension processes run with reduced privileges (low integrity on Windows, restricted sandbox on macOS/Linux)
5. Test that native messaging hosts are the only permitted mechanism for system access
6. Verify that extension APIs providing system access (chrome.system.*) are themselves sandboxed and permission-gated
7. Test that renderer process crashes are isolated and don't affect browser stability
8. Confirm that extension processes run in a restricted sandbox with limited system access
9. Verify that direct file system access outside storage APIs is blocked
10. Check that system command execution is prevented
11. Validate that extension processes have reduced privilege levels observable via platform tools
12. Confirm that native messaging is the only controlled pathway to system-level functionality
13. Verify that process isolation prevents extensions from affecting each other or the browser
14. Check that sandbox violations trigger security errors and process termination

**Pass Criteria**: Extension processes are sandboxed with restricted system access AND privilege level is verifiably reduced AND native messaging is the only system access pathway

**Fail Criteria**: Extensions can perform system-level operations directly OR process privilege levels are not reduced OR sandbox can be escaped

**Evidence**: Process Explorer/Activity Monitor screenshots showing sandbox status, test results demonstrating blocked system operations, platform-specific sandbox verification (integrity levels, sandbox profiles), crash logs showing isolation

**References**:

- Chrome Sandbox Architecture: https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md
- Extension Process Model: https://developer.chrome.com/docs/extensions/mv3/architecture-overview/
- Native Messaging: https://developer.chrome.com/docs/extensions/mv3/nativeMessaging/
- CWE-269: Improper Privilege Management: https://cwe.mitre.org/data/definitions/269.html
- Browser Sandbox Comparison: https://wiki.mozilla.org/Security/Sandbox
- Chrome Extension Security Architecture: https://www.chromium.org/Home/chromium-security/extension-content-script-fetches/

### Assessment: EXT-REQ-6 (Cross-extension isolation)

**Reference**: EXT-REQ-6 - Browser shall isolate extensions from each other to prevent unauthorized inter-extension communication

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

**Task**: Verify that the browser enforces complete isolation between different extensions to prevent malicious or compromised extensions from stealing data, intercepting communications, or exploiting capabilities of other installed extensions, ensuring that each extension operates within its own security boundary and can only interact with others through explicitly configured and consent-based channels.

**Verification**:

1. Install two test extensions (Extension A and Extension B) with different extension IDs
2. From Extension A, attempt to access Extension B's resources:
   - Try to load Extension B's background page scripts
   - Attempt to access Extension B's storage (chrome.storage.local)
   - Try to send messages to Extension B using chrome.runtime.sendMessage(extensionBId, message)
3. Verify that direct access to another extension's resources is blocked
4. Test that only explicitly externally_connectable extensions can receive messages from other extensions
5. Create Extension B with externally_connectable manifest key allowing Extension A
6. Verify that messaging now works but only in the declared direction
7. Test that extensions cannot inject content scripts into each other's extension pages
8. Verify that web_accessible_resources from one extension cannot be accessed by another extension's content scripts without explicit configuration
9. Test that extension storage is strictly isolated between extensions
10. Confirm that extensions cannot access each other's background pages, storage, or internal resources by default
11. Verify that cross-extension messaging only works when explicitly configured via externally_connectable
12. Check that content script injection into other extensions' pages is blocked
13. Validate that extension storage is completely isolated per extension ID
14. Confirm that web-accessible resources have controlled access between extensions
15. Verify that attempts to access other extensions' resources throw security errors

**Pass Criteria**: Complete isolation between extensions by default AND externally_connectable controls messaging AND storage is isolated

**Fail Criteria**: Any unauthorized access between extensions OR messaging works without externally_connectable OR storage isolation fails

**Evidence**: Console screenshots showing cross-extension access errors, test results with and without externally_connectable, storage isolation verification, messaging test results

**References**:

- Chrome Extensions Externally Connectable: https://developer.chrome.com/docs/extensions/mv3/manifest/externally_connectable/
- Extension Messaging: https://developer.chrome.com/docs/extensions/mv3/messaging/
- Web Accessible Resources: https://developer.chrome.com/docs/extensions/mv3/manifest/web_accessible_resources/
- CWE-668: Exposure of Resource to Wrong Sphere: https://cwe.mitre.org/data/definitions/668.html
- Extension Security Model: https://developer.chrome.com/docs/extensions/mv3/security/
- Mozilla Extension Communication: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts#communicating_with_background_scripts

### Assessment: EXT-REQ-7 (Host permissions validation)

**Reference**: EXT-REQ-7 - Browser shall validate and enforce host permissions declared in extension manifests

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

**Task**: Verify that the browser strictly enforces host permission declarations to prevent extensions from accessing arbitrary websites beyond their stated functionality, protecting users from extensions that attempt to steal credentials, intercept traffic, or exfiltrate data from unrelated sites, while ensuring that wildcard patterns and permission grants are clearly communicated and user-controllable.

**Verification**:

1. Create a test extension with specific host_permissions: `["https://example.com/*", "https://*.test.com/*"]`
2. Attempt to inject content scripts into various URLs:
   - Allowed: https://example.com/page, https://sub.test.com/page
   - Blocked: https://example.org/, https://different.com/, https://test.com.evil.com/
3. Test chrome.webRequest API interception with various URL patterns
4. Verify that fetch() and XMLHttpRequest from extension contexts respect host permissions
5. Test that host permission grants are persistent and revocable by users
6. Verify that optional host permissions require user interaction to grant
7. Test wildcard host permission patterns (<all_urls>, *://*/*) and verify appropriate warnings
8. Test that activeTab permission provides temporary access to current tab without broad host permissions
9. Verify that host permissions are enforced consistently across all extension APIs (tabs, webRequest, scripting, etc.)
10. Confirm that content scripts can only inject into URLs matching host_permissions patterns
11. Verify that host permission patterns are correctly parsed and enforced (wildcards, subdomains, paths)
12. Check that network requests from extensions are blocked to non-permitted hosts
13. Validate that users can view and revoke host permissions through extension management UI
14. Confirm that optional host permissions require explicit user grant
15. Verify that broad permissions like <all_urls> show prominent warnings during install
16. Check that activeTab provides scoped, temporary permissions without persistent broad access

**Pass Criteria**: Host permissions are enforced across all APIs AND wildcard patterns work correctly AND users can control permissions AND activeTab provides limited scope

**Fail Criteria**: Extensions access hosts beyond declared permissions OR permission patterns are incorrectly parsed OR user controls are ineffective

**Evidence**: Test results showing blocked/allowed access by host, permission management UI screenshots, installation warning screenshots for broad permissions, activeTab test results

**References**:

- Chrome Host Permissions: https://developer.chrome.com/docs/extensions/mv3/match_patterns/
- ActiveTab Permission: https://developer.chrome.com/docs/extensions/mv3/manifest/activeTab/
- Optional Permissions: https://developer.chrome.com/docs/extensions/reference/permissions/
- User Control of Extension Permissions: https://developer.chrome.com/docs/extensions/mv3/permission_warnings/
- CWE-284: Improper Access Control: https://cwe.mitre.org/data/definitions/284.html
- Mozilla Match Patterns: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Match_patterns

### Assessment: EXT-REQ-8 (CSP for extensions)

**Reference**: EXT-REQ-8 - Browser shall enforce Content Security Policy for extension pages and prevent unsafe code execution

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

**Task**: Verify that the browser enforces strict Content Security Policy on extension pages to prevent malicious or compromised extensions from executing arbitrary remote code, using eval-based code injection, or loading scripts from attacker-controlled servers, mitigating the risk of extensions becoming vectors for code injection attacks or post-install malicious behavior updates.

**Verification**:

1. Create a test extension with default CSP (Manifest V3 default: `script-src 'self'; object-src 'self'`)
2. In the extension's popup or background page, attempt to:
   - Execute inline scripts: `<script>alert('test')</script>`
   - Use eval(): `eval("alert('test')")`
   - Use Function constructor: `new Function("alert('test')")`
   - Load external scripts from CDNs: `<script src="https://cdn.example.com/lib.js">`
   - Use inline event handlers: `<button onclick="handleClick()">Click</button>`
3. Verify that all unsafe code execution attempts are blocked with CSP violations
4. Test that extension CSP cannot be relaxed to allow unsafe-eval or unsafe-inline in Manifest V3
5. Verify that remote code loading is blocked in Manifest V3
6. Test that sandboxed pages in extensions can have relaxed CSP but remain isolated
7. Monitor browser console for CSP violation reports
8. Test WASM execution with wasm-unsafe-eval directive requirements
9. Confirm that extension pages enforce strict CSP by default
10. Verify that inline scripts, eval(), and Function constructor are blocked
11. Check that remote code loading from CDNs is blocked
12. Validate that CSP violations are logged to console with clear messages
13. Confirm that Manifest V3 prevents CSP relaxation to unsafe-eval or unsafe-inline
14. Verify that sandboxed extension pages can have different CSP but remain isolated
15. Check that only local scripts from the extension package can execute

**Pass Criteria**: Strict CSP is enforced on all extension pages AND remote code is blocked AND CSP cannot be weakened in Manifest V3

**Fail Criteria**: Unsafe code execution succeeds OR remote scripts load OR CSP can be bypassed

**Evidence**: Console screenshots showing CSP violations, test results for eval/inline scripts/remote code, manifest CSP configuration examples, sandboxed page test results

**References**:

- Extension Content Security Policy: https://developer.chrome.com/docs/extensions/mv3/manifest/content_security_policy/
- Manifest V3 CSP Changes: https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/#content-security-policy
- CSP Specification: https://www.w3.org/TR/CSP3/
- Sandboxed Pages in Extensions: https://developer.chrome.com/docs/extensions/mv3/manifest/sandbox/
- CWE-94: Improper Control of Generation of Code: https://cwe.mitre.org/data/definitions/94.html
- Mozilla Extension CSP: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy

### Assessment: EXT-REQ-9 (WebRequest API security)

**Reference**: EXT-REQ-9 - Browser shall secure the WebRequest API to prevent malicious request interception and modification

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

**Task**: Verify that the browser secures the WebRequest API to prevent malicious extensions from performing man-in-the-middle attacks, stealing authentication tokens, modifying banking transactions, or blocking security updates, while ensuring that Manifest V3's declarativeNetRequest provides necessary functionality with reduced attack surface through rule validation, limits, and sensitive header protections.

**Verification**:

1. Create test extensions using declarativeNetRequest API (Manifest V3):
   - Rules to block specific URLs
   - Rules to redirect requests
   - Rules to modify request headers
   - Rules to modify response headers
2. Verify that declarativeNetRequest rules are validated before installation
3. Test that rule limits are enforced (static rules, dynamic rules, session rules)
4. Attempt to create overly broad rules that would affect all network traffic
5. Verify that sensitive headers (Cookie, Authorization) have restricted modification capabilities
6. Test that extensions cannot intercept requests to chrome:// or chrome-extension:// schemes
7. Verify that declarativeNetRequest is more restrictive than legacy webRequest blocking
8. Test that multiple extensions with conflicting rules have predictable precedence
9. Verify that users are warned about extensions with webRequest permissions (Manifest V2) or declarativeNetRequest (Manifest V3)
10. Confirm that declarativeNetRequest rules are validated and enforced
11. Verify that rule count limits prevent resource exhaustion
12. Check that sensitive headers have protection against modification
13. Validate that browser internal URLs are protected from interception
14. Confirm that Manifest V3 declarativeNetRequest is more restrictive than Manifest V2 webRequest
15. Verify that rule conflicts between extensions are resolved predictably
16. Check that permission warnings clearly communicate network interception capabilities

**Pass Criteria**: DeclarativeNetRequest enforces rule validation and limits AND sensitive contexts are protected AND permission warnings are clear

**Fail Criteria**: Invalid rules are accepted OR no rule limits OR internal URLs can be intercepted OR no permission warnings

**Evidence**: Test results showing rule validation, screenshots of rule limits enforcement, header modification test results, permission warning screenshots, conflict resolution examples

**References**:

- Chrome DeclarativeNetRequest API: https://developer.chrome.com/docs/extensions/reference/declarativeNetRequest/
- Manifest V3 WebRequest Changes: https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/#modifying-network-requests
- DeclarativeNetRequest Rule Limits: https://developer.chrome.com/docs/extensions/reference/declarativeNetRequest/#limits
- Mozilla WebRequest API: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest
- CWE-300: Channel Accessible by Non-Endpoint: https://cwe.mitre.org/data/definitions/300.html
- Extension Network Request Security: https://developer.chrome.com/docs/extensions/mv3/security/#network-requests

### Assessment: EXT-REQ-10 (Extension update verification)

**Reference**: EXT-REQ-10 - Browser shall cryptographically verify extension updates before installation

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

**Task**: Verify that the browser cryptographically verifies all extension updates to prevent attackers from distributing malware through compromised update servers, man-in-the-middle attacks, or extension ID hijacking, ensuring that only authentic updates signed by the original developer can replace installed extensions and protecting users from supply chain attacks.

**Verification**:

1. Install a test extension from the Chrome Web Store or addons.mozilla.org
2. Monitor the extension update process using browser internals (chrome://extensions, about:debugging)
3. Configure a local web server to serve a modified version of the extension with:
   - Invalid signature
   - Mismatched extension ID
   - Tampered CRX/XPI file
4. Attempt to force the browser to update from the malicious server
5. Verify that the browser rejects the tampered update
6. Test that update_url in manifest should point to official web stores for published extensions
7. Verify that self-hosted extensions require proper signatures
8. Test CRX3 signature verification (Chrome) or signed XPI verification (Firefox)
9. Monitor network traffic to verify updates use HTTPS
10. Test that update checks include extension ID, version, and signature verification
11. Confirm that all extension updates are downloaded over HTTPS
12. Verify that CRX/XPI file signatures are cryptographically verified before installation
13. Check that tampered updates are rejected with error messages
14. Validate that extension ID shall match between installed extension and update
15. Confirm that update URLs should be HTTPS and point to trusted sources
16. Verify that self-hosted extensions require proper code signing
17. Check that update process cannot be MITM attacked to install malicious code

**Pass Criteria**: All updates are signature-verified AND tampered updates are rejected AND HTTPS is enforced AND extension ID matching is enforced

**Fail Criteria**: Unsigned or tampered updates install successfully OR HTTP update URLs work OR extension ID mismatch is allowed

**Evidence**: Network captures showing HTTPS update checks, logs of rejected tampered updates, signature verification test results, CRX/XPI file inspection showing signatures

**References**:

- Chrome CRX3 Extension Format: https://chromium.googlesource.com/chromium/src/+/master/components/crx_file/crx3.proto
- Chrome Extension Update Mechanism: https://developer.chrome.com/docs/extensions/mv3/linux_hosting/#update
- Mozilla Extension Signing: https://extensionworkshop.com/documentation/publish/signing-and-distribution-overview/
- CWE-494: Download of Code Without Integrity Check: https://cwe.mitre.org/data/definitions/494.html
- Extension Package Security: https://www.chromium.org/Home/chromium-security/extension-content-script-fetches/

### Assessment: EXT-REQ-11 (Extension storage isolation)

**Reference**: EXT-REQ-11 - Browser shall isolate extension storage to prevent unauthorized access between extensions and web pages

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

**Task**: Verify that the browser isolates extension storage to prevent malicious extensions from stealing API keys, authentication tokens, or user data stored by other extensions, and to prevent web pages from accessing extension storage to exfiltrate sensitive information, ensuring that each extension's storage remains private and accessible only within its own security context.

**Verification**:

1. Create Extension A that stores sensitive data in chrome.storage.local and chrome.storage.sync:
   ```javascript
   chrome.storage.local.set({secret: "extension_A_secret"});
   chrome.storage.sync.set({syncData: "extension_A_sync"});
   ```
2. Create Extension B that attempts to read Extension A's storage:
   ```javascript
   chrome.storage.local.get("secret", (result) => console.log(result));
   ```
3. Verify that Extension B cannot access Extension A's storage
4. Create a web page that attempts to access extension storage using various methods:
   - Direct chrome.storage access
   - IndexedDB inspection for extension storage
   - File system access to extension storage location
5. Verify that web pages have no access to extension storage