EN-304-617_v0.0.5.md

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

1. Configure enterprise policies that create isolation exceptions for specific origins → Test that log entries distinguish between policy-based exceptions and standard CORS/postMessage
2. Access the browser's logging interface (console logs, diagnostic logs, or audit logs) → Verify that logs can be exported or forwarded to SIEM systems
3. Trigger cross-origin interactions that invoke policy-based exceptions → Confirm that logging does not expose sensitive user data
4. Verify that each exception usage is logged with relevant details: → Test that log volume is reasonable and does not impact browser performance
   - Timestamp of the exception
   - Source and target origins involved
   - Policy name or identifier that permitted the exception
   - Type of isolation relaxation (storage access, DOM access, etc.)
5. Test that logs include sufficient information for security auditing → Verify that logs persist across browser restarts
6. Verify that logs are written to a location accessible to security teams → Validate that disabled logging can be detected by monitoring systems

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

## 6.2 Extension System Security Assessments

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

1. Load a test extension and identify its background service worker process using browser task manager or process explorer → Confirm that extension processes run in a restricted sandbox with limited system access
2. Attempt to execute operations that require system-level privileges from the extension: → Verify that direct file system access outside storage APIs is blocked
   - File system access outside of extension storage APIs
   - 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: → Check that system command execution is prevented
   - 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) → Validate that extension processes have reduced privilege levels observable via platform tools
5. Test that native messaging hosts are the only permitted mechanism for system access → Confirm that native messaging is the only controlled pathway to system-level functionality
6. Verify that extension APIs providing system access (system information interfaces) are themselves sandboxed and permission-gated → Verify that process isolation prevents extensions from affecting each other or the browser
7. Test that renderer process crashes are isolated and don't affect browser stability → 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 → Verify that web_accessible_resources from one extension cannot be accessed by another extension's content scripts without explicit configuration
2. From Extension A, attempt to access Extension B's resources: → Test that extension storage is strictly isolated between extensions
   - Try to load Extension B's background page scripts
   - Attempt to access Extension B's storage (extension storage API)
   - Try to send messages to Extension B using the extension runtime messaging API
3. Verify that direct access to another extension's resources is blocked → Confirm that extensions cannot access each other's background pages, storage, or internal resources by default
4. Test that only explicitly externally_connectable extensions can receive messages from other extensions → Verify that cross-extension messaging only works when explicitly configured via externally_connectable
5. Create Extension B with externally_connectable manifest key allowing Extension A → Check that content script injection into other extensions' pages is blocked
6. Verify that messaging now works but only in the declared direction → Validate that extension storage is completely isolated per extension ID
7. Test that extensions cannot inject content scripts into each other's extension pages → Confirm that web-accessible resources have controlled access between extensions

**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/*"]` → Verify that host permissions are enforced consistently across all extension APIs (tabs, webRequest, scripting, etc.)
2. Attempt to inject content scripts into various URLs: → Confirm that content scripts can only inject into URLs matching host_permissions patterns
   - Allowed: https://example.com/page, https://sub.test.com/page
   - Blocked: https://example.org/, https://different.com/, https://test.com.evil.com/
3. Test web request interception API with various URL patterns → Verify that host permission patterns are correctly parsed and enforced (wildcards, subdomains, paths)
4. Verify that fetch() and XMLHttpRequest from extension contexts respect host permissions → Check that network requests from extensions are blocked to non-permitted hosts
5. Test that host permission grants are persistent and revocable by users → Validate that users can view and revoke host permissions through extension management UI
6. Verify that optional host permissions require user interaction to grant → Confirm that optional host permissions require explicit user grant
7. Test wildcard host permission patterns (<all_urls>, *://*/*) and verify appropriate warnings → Verify that broad permissions like <all_urls> show prominent warnings during install
8. Test that activeTab permission provides temporary access to current tab without broad host permissions → 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'`) → Test WASM execution with wasm-unsafe-eval directive requirements
2. In the extension's popup or background page, attempt to: → Confirm that extension pages enforce strict CSP by default
   - 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 → Verify that inline scripts, eval(), and Function constructor are blocked
4. Test that extension CSP cannot be relaxed to allow unsafe-eval or unsafe-inline in Manifest V3 → Check that remote code loading from CDNs is blocked
5. Verify that remote code loading is blocked in Manifest V3 → Validate that CSP violations are logged to console with clear messages
6. Test that sandboxed pages in extensions can have relaxed CSP but remain isolated → Confirm that Manifest V3 prevents CSP relaxation to unsafe-eval or unsafe-inline
7. Monitor browser console for CSP violation reports → Verify that sandboxed extension pages can have different CSP but remain isolated

**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): → Verify that users are warned about extensions with webRequest permissions (Manifest V2) or declarativeNetRequest (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 → Confirm that declarativeNetRequest rules are validated and enforced
3. Test that rule limits are enforced (static rules, dynamic rules, session rules) → Verify that rule count limits prevent resource exhaustion
4. Attempt to create overly broad rules that would affect all network traffic → Check that sensitive headers have protection against modification
5. Verify that sensitive headers (Cookie, Authorization) have restricted modification capabilities → Validate that browser internal URLs are protected from interception
6. Test that extensions cannot intercept requests to browser internal or extension schemes → Confirm that Manifest V3 declarativeNetRequest is more restrictive than Manifest V2 webRequest
7. Verify that declarativeNetRequest is more restrictive than legacy webRequest blocking → Verify that rule conflicts between extensions are resolved predictably
8. Test that multiple extensions with conflicting rules have predictable precedence → 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 an official extension store → Monitor network traffic to verify updates use HTTPS
2. Monitor the extension update process using browser internals (extension management interface, debugging tools) → Test that update checks include extension ID, version, and signature verification
3. Configure a local web server to serve a modified version of the extension with: → Confirm that all extension updates are downloaded over HTTPS
   - Invalid signature
   - Mismatched extension ID
   - Tampered CRX/XPI file
4. Attempt to force the browser to update from the malicious server → Verify that extension package file signatures are cryptographically verified before installation
5. Verify that the browser rejects the tampered update → Check that tampered updates are rejected with error messages
6. Test that update_url in manifest should point to official web stores for published extensions → Validate that extension ID shall match between installed extension and update
7. Verify that self-hosted extensions require proper signatures → Confirm that update URLs should be HTTPS and point to trusted sources
8. Test extension package signature verification for the browser's package format → Verify that self-hosted extensions require proper code signing

**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 local and sync storage APIs: → Verify that sync storage API has appropriate sync limits and encryption
   ```javascript
   browser.storage.local.set({secret: "extension_A_secret"});
   browser.storage.sync.set({syncData: "extension_A_sync"});
   ```
2. Create Extension B that attempts to read Extension A's storage: → Confirm that each extension has isolated storage inaccessible to other extensions
   ```javascript
   browser.storage.local.get("secret", (result) => console.log(result));
   ```
3. Verify that Extension B cannot access Extension A's storage → Verify that web pages cannot access any extension storage APIs or data
4. Create a web page that attempts to access extension storage using various methods: → Check that extension storage persists across sessions but is removed on uninstall
   - Direct extension storage API access
   - IndexedDB inspection for extension storage
   - File system access to extension storage location
5. Verify that web pages have no access to extension storage → Validate that storage quota limits are enforced per extension
6. Test that extension storage persists across browser restarts → Confirm that sync storage API uses encrypted sync when user is signed in
7. Verify that uninstalling an extension removes its storage → Verify that no file system or database tools can access extension storage from outside the browser
8. Test extension storage quota limits and enforcement → Check that storage access from wrong context results in clear error messages

**Pass Criteria**: Complete storage isolation between extensions AND no web page access AND proper quota enforcement AND sync encryption

**Fail Criteria**: Cross-extension storage access succeeds OR web pages can read extension storage OR no quota enforcement

**Evidence**: Test results showing isolation between extensions, console errors from web pages attempting access, persistent storage verification, quota limit test results, sync encryption verification

**References**:

- Chrome Storage API: https://developer.chrome.com/docs/extensions/reference/storage/
- Storage Quota Limits: https://developer.chrome.com/docs/extensions/reference/storage/#property-sync-QUOTA_BYTES
- Mozilla Storage API: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage
- Storage Sync Security: https://developer.chrome.com/docs/extensions/reference/storage/#property-sync
- CWE-552: Files or Directories Accessible to External Parties: https://cwe.mitre.org/data/definitions/552.html
- Extension Data Security: https://developer.chrome.com/docs/extensions/mv3/security/#data

### Assessment: EXT-REQ-12 (Background script restrictions)

**Reference**: EXT-REQ-12 - Browser shall enforce restrictions on background scripts including service worker lifecycle and capabilities

**Given**: A conformant browser with EXT-2 or higher capability (Manifest V3)

**Task**: Verify that the browser enforces service worker lifecycle restrictions for background scripts to reduce resource consumption, prevent persistent background pages that could perform long-term surveillance or crypto-mining, and ensure that extensions cannot maintain always-on processes that degrade performance or bypass browser power management, while maintaining security through strict CSP enforcement.

**Verification**:

1. Create a Manifest V3 extension with a background service worker → Verify CSP enforcement in service worker context
2. Verify that background pages (persistent background scripts) are not allowed in Manifest V3 → Confirm that Manifest V3 extensions use service workers, not persistent background pages
3. Test service worker lifecycle: → Verify that service workers terminate after idle timeout and restart on events
   - Service worker starts on extension events (installation, message, alarm)
   - Service worker terminates after idle timeout (~30 seconds)
   - Service worker restarts when needed for events
4. Attempt to use browser APIs not available in service workers: → Check that DOM APIs are unavailable in service worker context
   - DOM APIs (document, window)
   - Synchronous storage APIs
   - XMLHttpRequest (should use fetch instead)
5. Verify that service workers cannot use eval() or other dynamic code execution → Validate that dynamic code execution is blocked in service workers
6. Test that long-running operations should use alarms API or native messaging → Confirm that service worker lifecycle is managed by the browser, not the extension
7. Verify that service worker registration is automatic and cannot be modified → Verify that long-running tasks should use appropriate APIs (alarms, native messaging)
8. Test that service worker cannot be kept alive artificially → Check that service worker CSP is strict and enforced

**Pass Criteria**: Service worker lifecycle is enforced AND unavailable APIs throw errors AND CSP is enforced AND artificial keep-alive is prevented

**Fail Criteria**: Persistent background pages work in Manifest V3 OR service worker doesn't terminate OR restricted APIs are available

**Evidence**: Test results showing service worker termination, console errors for unavailable APIs, lifecycle event logs, CSP violation logs, timing tests showing automatic termination

**References**:

- Manifest V3 Service Workers: https://developer.chrome.com/docs/extensions/mv3/migrating_to_service_workers/
- Service Worker Lifecycle: https://developer.chrome.com/docs/extensions/mv3/service_workers/
- Background Script Migration: https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/#background-service-workers
- Service Workers in Extensions: https://developer.chrome.com/docs/extensions/mv3/service_workers/basics/
- CWE-405: Asymmetric Resource Consumption: https://cwe.mitre.org/data/definitions/405.html
- Extension Service Worker Events: https://developer.chrome.com/docs/extensions/mv3/service_workers/events/

### Assessment: EXT-REQ-13 (Manifest V3 compliance)

**Reference**: EXT-REQ-13 - Browser shall enforce Manifest V3 security requirements for new and updated extensions

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

**Task**: Verify that the browser enforces Manifest V3 security requirements to prevent extensions from using deprecated, insecure patterns such as persistent background pages that enable surveillance, blocking webRequest that enables man-in-the-middle attacks, relaxed CSP that allows remote code execution, and callback-based APIs prone to timing attacks, ensuring all new extensions benefit from modern security architecture.

**Verification**:

1. Verify that browser supports Manifest V3 extensions → Test migration path from V2 to V3 with breaking changes properly surfaced
2. Test that new extension submissions require Manifest V3 (check store policies) → Confirm that browser fully supports Manifest V3 specification
3. Create test extensions demonstrating Manifest V3 security improvements: → Verify that Manifest V2 deprecated features are rejected in Manifest V3 extensions
   - Service workers instead of persistent background pages
   - DeclarativeNetRequest instead of blocking webRequest
   - Strict CSP with no unsafe-eval
   - No remote code execution
   - Promises-based APIs instead of callbacks
4. Attempt to use deprecated Manifest V2 features in Manifest V3 extension: → Check that security improvements (service workers, declarativeNetRequest, strict CSP) are enforced
   - background.persistent
   - background.page
   - webRequest blocking with broad host permissions
   - Relaxed CSP with unsafe-eval
5. Verify that browser rejects or warns about Manifest V2 features in Manifest V3 context → Validate that clear error messages guide developers away from deprecated patterns
6. Test that Manifest V2 extensions show deprecation warnings → Confirm that Manifest V2 extensions show deprecation warnings to users
7. Verify manifest_version field validation (should be 2 or 3, with 3 preferred) → Verify that extension stores enforce Manifest V3 for new submissions

**Pass Criteria**: Manifest V3 security requirements are fully enforced AND deprecated V2 features are rejected AND clear migration guidance exists

**Fail Criteria**: V2 deprecated features work in V3 extensions OR no enforcement of V3 security model OR no deprecation warnings

**Evidence**: Manifest validation test results, deprecation warning screenshots, test extensions demonstrating V3 features, store policy documentation, migration guide references

**References**:

- Manifest V3 Overview: https://developer.chrome.com/docs/extensions/mv3/intro/
- Manifest V3 Migration Guide: https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/
- Manifest V3 Platform Vision: https://developer.chrome.com/docs/extensions/mv3/intro/platform-vision/
- Mozilla Manifest V3: https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-firefox-recap-next-steps/
- CWE-477: Use of Obsolete Function: https://cwe.mitre.org/data/definitions/477.html
- Manifest V3 Security Improvements: https://developer.chrome.com/docs/extensions/mv3/intro/mv3-overview/#security

### Assessment: EXT-REQ-14 (Native messaging security)

**Reference**: EXT-REQ-14 - Browser shall secure native messaging to prevent unauthorized native application access

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

**Task**: Verify that the browser secures native messaging to prevent malicious extensions from escaping the browser sandbox by connecting to arbitrary native applications, installing native malware disguised as messaging hosts, or using native messaging as a privilege escalation vector, ensuring that only explicitly whitelisted extensions can communicate with user-installed, validated native applications.

**Verification**:

1. Create a native messaging host application with a manifest file → Verify that native host processes run with appropriate user privileges (not elevated)
2. Register the native messaging host according to platform requirements: → Confirm that native messaging requires explicit nativeMessaging permission
   - Windows: Registry entry under HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE
   - macOS/Linux: JSON manifest in specified directories
3. Create an extension with nativeMessaging permission and allowed_origins in native host manifest → Verify that native host manifest should acceptlist extension IDs in allowed_origins
4. Test communication between extension and native host using chrome.runtime.connectNative() → Check that unlisted extensions cannot connect to native hosts
5. Verify that only extensions listed in native host manifest's allowed_origins can connect → Validate that native host executable path is validated against tampering
6. Attempt connection from an unlisted extension and verify rejection → Confirm that extensions cannot download or install native hosts programmatically
7. Test that native host path validation prevents directory traversal → Verify that message passing is properly sandboxed and size-limited
8. Verify that native messaging requires user-installed native applications (not downloadable by extensions) → Check that native hosts run without elevated privileges
9. Test message size limits and validation → Validate that connection attempts from unauthorized extensions fail with clear errors

**Pass Criteria**: Native messaging requires permission and allowed_origins whitelisting AND path validation prevents tampering AND extensions cannot install hosts

**Fail Criteria**: Any extension can connect to native hosts OR path validation is bypassable OR extensions can install native hosts programmatically

**Evidence**: Test results showing connection rejection for unlisted extensions, native host manifest examples, registry/filesystem inspection showing host registration, message passing test results, privilege level verification

**References**:

- Chrome Native Messaging: https://developer.chrome.com/docs/extensions/mv3/nativeMessaging/
- Native Messaging Host Protocol: https://developer.chrome.com/docs/extensions/mv3/nativeMessaging/#native-messaging-host-protocol
- Mozilla Native Messaging: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging
- Native Host Manifest Format: https://developer.chrome.com/docs/extensions/mv3/nativeMessaging/#native-messaging-host
- CWE-494: Download of Code Without Integrity Check: https://cwe.mitre.org/data/definitions/494.html
- Extension-Native App Security: https://developer.chrome.com/docs/extensions/mv3/security/#native-messaging

### Assessment: EXT-REQ-15 (Extension-controlled web content)

**Reference**: EXT-REQ-15 - Browser shall prevent extensions from injecting malicious content or deceptively modifying web pages

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

**Task**: Verify that the browser prevents extensions from injecting malicious content into web pages to conduct phishing attacks, overlaying fake login forms to steal credentials, intercepting form submissions to capture banking details, or deceptively modifying trusted website content, while ensuring that legitimate content script functionality is appropriately permission-gated and user-visible through DevTools attribution.

**Verification**:

1. Create test extensions that attempt various forms of web content modification: → Verify CSP restrictions prevent content scripts from loading remote code
   - Injecting scripts into web pages via content scripts
   - Modifying DOM to overlay fake UI elements (e.g., fake login forms)
   - Intercepting and modifying form submissions
   - Replacing legitimate content with malicious content
2. Verify that content script capabilities are limited by Content Security Policy → Confirm that content scripts require declared host permissions
3. Test that extensions should declare host permissions for content script injection → Verify that browser UI pages and other extensions are protected from content script injection
4. Create a test extension that attempts to: → Check that broad host permissions trigger prominent installation warnings
   - Inject content scripts into browser UI pages (internal browser schemes)
   - Inject into other extensions' pages
   - Inject into local file:// URLs without explicit permission
5. Verify that such injections are blocked → Validate that content script modifications are attributable in DevTools
6. Test that users are warned about extensions with broad host permissions during installation → Confirm that incognito mode requires explicit extension permission
7. Verify that content script modifications are visible in DevTools with extension attribution → Verify that CSP prevents content scripts from loading remote malicious code
8. Test that extensions cannot inject content into incognito mode without explicit permission → Check that file:// access requires explicit user permission

**Pass Criteria**: Content scripts are permission-gated AND sensitive contexts are protected AND user warnings are clear AND DevTools attribution works

**Fail Criteria**: Content scripts inject without permissions OR browser pages are injectable OR no user warnings OR no attribution

**Evidence**: Permission prompt screenshots, test results showing blocked injections, DevTools showing extension attribution, CSP enforcement test results, incognito permission tests

**References**:

- Content Scripts Security: https://developer.chrome.com/docs/extensions/mv3/content_scripts/#security
- Extension Content Script Injection: https://developer.chrome.com/docs/extensions/mv3/content_scripts/#programmatic
- Mozilla Content Scripts: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts
- Incognito Mode for Extensions: https://developer.chrome.com/docs/extensions/mv3/manifest/incognito/
- CWE-79: Cross-site Scripting (XSS): https://cwe.mitre.org/data/definitions/79.html
- Extension Security Best Practices: https://extensionworkshop.com/documentation/develop/build-a-secure-extension/

### Assessment: EXT-REQ-16 (Extension telemetry privacy)

**Reference**: EXT-REQ-16 - Browser shall ensure extension telemetry and error reporting respect user privacy

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

**Task**: Verify that the browser ensures extension telemetry and error reporting respect user privacy to prevent extensions from exfiltrating browsing history, capturing personally identifiable information, or using analytics to track users across the web without consent, while ensuring that extension developers disclose data collection practices and that sensitive information is not inadvertently leaked through error reports or console logs.

**Verification**:

1. Install a test extension with error reporting or analytics code → Monitor for sensitive data leakage in extension console logs (passwords, tokens, PII)
2. Monitor network traffic from the extension using browser DevTools or external proxy (e.g., Burp Suite, mitmproxy) → Verify that extension store policies require privacy disclosures for data collection
3. Verify that extensions cannot access browser telemetry or crash reporting APIs directly → Confirm that extensions have no access to browser telemetry APIs
4. Test that extension storage sync does not leak data to unauthorized parties → Verify that extension-to-server communications are visible and monitorable by users
5. Verify that error reporting from extensions requires user consent if it includes: → Check that sensitive user data is not included in extension error reports without consent
   - URLs visited by the user
   - Personal identifiable information
   - Browsing history or patterns
6. Test that sync storage API encryption prevents extension from reading other extensions' sync data → Validate that sync storage API data is encrypted and isolated
7. Verify that extensions should declare and justify data collection in privacy policies → Confirm that extension developers shall disclose data collection practices
8. Test that extensions cannot access browser's own telemetry data → Verify that console logs do not inadvertently expose sensitive data

**Pass Criteria**: Extensions cannot access browser telemetry AND user consent is required for sensitive data collection AND privacy policies are required

**Fail Criteria**: Extensions access browser telemetry OR sensitive data is transmitted without consent OR no privacy policy requirements

**Evidence**: Network traffic captures showing extension communications, test results showing blocked telemetry API access, privacy policy examples from extension stores, storage sync encryption verification

**References**:

- Chrome Extension Privacy Practices: https://developer.chrome.com/docs/extensions/mv3/user_privacy/
- Extension Privacy Policy Requirements: https://developer.chrome.com/docs/webstore/program-policies/privacy/
- Mozilla Data Collection Guidelines: https://extensionworkshop.com/documentation/publish/add-on-policies/#data-disclosure-collection-and-management
- GDPR Compliance for Extensions: https://gdpr.eu/what-is-gdpr/
- CWE-359: Exposure of Private Personal Information: https://cwe.mitre.org/data/definitions/359.html

### Assessment: EXT-REQ-17 (Extension signature validation)

**Reference**: EXT-REQ-17 - Browser shall validate cryptographic signatures of extensions before installation and during runtime

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

**Task**: Verify that the browser validates cryptographic signatures of extensions to prevent installation of tampered, backdoored, or malicious extensions distributed through compromised channels, ensuring that only extensions authenticated by trusted authorities or the original developer can be installed, and that signature validation provides defense-in-depth against supply chain attacks and extension package manipulation.

**Verification**:

1. Download a legitimate signed extension from an official extension store → Test that extension updates have been signed by the same key as the original
2. Inspect the extension package to verify signature presence → Confirm that all production extensions have valid cryptographic signatures
3. Use tools to verify the signature according to the browser's package format and signing infrastructure → Verify that signatures are verified at installation time
4. Attempt to install a modified extension with: → Check that invalid, expired, or missing signatures prevent installation
   - Invalid signature
   - No signature
   - Expired signature
   - Signature from untrusted authority
5. Verify that the browser rejects all invalid signatures with clear error messages → Validate that developer mode allows unsigned extensions with prominent warnings
6. Test that extensions loaded in developer mode can bypass signature requirements (but with clear warnings) → Confirm that signature validation uses trusted certificate authorities
7. Verify that production extensions require valid signatures from trusted authorities → Verify that certificate revocation is checked during validation
8. Test that signature validation occurs at both install time and runtime → Check that extension updates require signature continuity (same signing key)
9. Verify that browser checks certificate revocation for extension signatures → Validate that clear error messages explain signature validation failures

**Pass Criteria**: All production extensions require valid signatures AND signature validation is comprehensive AND update signature continuity is enforced

**Fail Criteria**: Unsigned extensions install in production mode OR signature validation is bypassable OR no certificate revocation checking

**Evidence**: CRX/XPI file inspection showing signatures, test results with tampered signatures, installation error screenshots, certificate chain verification, developer mode warning screenshots

**References**:

- Chrome CRX3 Format and Signing: https://chromium.googlesource.com/chromium/src/+/master/components/crx_file/crx3.proto
- Mozilla Extension Signing: https://extensionworkshop.com/documentation/publish/signing-and-distribution-overview/
- Extension Package Format: https://developer.chrome.com/docs/extensions/mv3/linux_hosting/#packaging
- Code Signing Best Practices: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Distribution
- CWE-345: Insufficient Verification of Data Authenticity: https://cwe.mitre.org/data/definitions/345.html
- Chrome Web Store Developer Policies: https://developer.chrome.com/docs/webstore/program-policies/

### Assessment: EXT-REQ-18 (Extension permissions UI transparency)

**Reference**: EXT-REQ-18 - Browser shall provide clear, understandable UI for extension permissions allowing informed user consent

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

**Task**: Verify that the browser provides clear, understandable permission UI to enable informed user consent, preventing extensions from deceiving users about their capabilities through technical jargon, hidden permission requests, or unclear warnings, ensuring that users understand what access they're granting and can make security-conscious decisions about extension installation, especially for high-risk permissions that could enable data theft or surveillance.

**Verification**:

1. Create test extensions with various permission combinations: → Test that broad permissions like <all_urls> have prominent, scary warnings
   - Low-risk permissions (storage, alarms)
   - Medium-risk permissions (tabs, activeTab)
   - High-risk permissions (webRequest, <all_urls>, cookies)
   - Sensitive permissions (debugger, management, privacy)
2. Install each extension and observe permission prompts → Confirm that permission prompts use clear, user-friendly language (not technical jargon)
3. Verify that permission prompts: → Verify that high-risk permissions have prominent warnings with specific explanations
   - Use clear, non-technical language
   - Group permissions by risk level
   - Explain what each permission allows
   - Show prominent warnings for dangerous permissions
4. Test that users can view current permissions in extension management UI → Check that users can view all extension permissions in management UI
5. Verify that users can revoke permissions without uninstalling extension → Validate that users can revoke individual permissions without uninstalling
6. Test optional permissions flow where extensions request additional permissions at runtime → Confirm that optional permissions require explicit user interaction to grant
7. Verify that permission grant/revocation is persistent across sessions → Verify that permission changes trigger new consent prompts
8. Test that permission changes trigger re-prompting for consent → Check that broad permissions have special warnings about privacy implications
9. Verify that extensions cannot request permissions programmatically without user interaction → Validate that permission UI is consistent across installation and runtime requests

**Pass Criteria**: Permission UI is clear and understandable AND risk-appropriate warnings are shown AND users have granular control AND persistent consent tracking

**Fail Criteria**: Permission language is too technical OR no risk differentiation OR users cannot revoke permissions OR no warnings for dangerous permissions

**Evidence**: Screenshots of permission prompts at various risk levels, extension management UI screenshots, optional permission flow recordings, user testing results demonstrating comprehension, revocation test results

**References**:

- Chrome Permission Warnings: https://developer.chrome.com/docs/extensions/mv3/permission_warnings/
- Mozilla Permission Requests: https://extensionworkshop.com/documentation/develop/request-the-right-permissions/
- Extension Permission UX Best Practices: https://developer.chrome.com/docs/extensions/mv3/permission_warnings/#permissions_with_warnings
- CWE-276: Incorrect Default Permissions: https://cwe.mitre.org/data/definitions/276.html
- Designing User-Friendly Permission Systems: https://extensionworkshop.com/documentation/develop/build-a-secure-extension/#request-permissions-at-runtime

### Assessment: EXT-REQ-19 (No extension support enforcement)

**Reference**: EXT-0-REQ-1 - Browser shall not provide any extension installation or execution capability

**Given**: A conformant browser with EXT-0 capability (no extension support)

**Task**: Verify that the browser completely disables extension installation and execution capabilities to eliminate the attack surface introduced by third-party code, preventing malicious extensions from harvesting user data, performing privilege escalation, or compromising browser security through extension APIs, ensuring that browsers in high-security environments operate without the risks associated with extension ecosystems.

**Verification**:

1. Attempt to access extension management interface through browser UI → Check that browser settings do not include extension-related configuration options
2. Verify that no extension installation options are available in menus or settings → Attempt to access extension APIs from web content or developer console