EN-304-617_v0.0.4.md

4. Verify that each exception usage is logged with relevant details:
   - Timestamp of the exception
   - Source and target origins involved
   - Policy name or identifier that permitted the exception
   - Type of isolation relaxation (storage access, DOM access, etc.)
5. Test that logs include sufficient information for security auditing
6. Verify that logs are written to a location accessible to security teams
7. Test that log entries distinguish between policy-based exceptions and standard CORS/postMessage
8. Verify that logs can be exported or forwarded to SIEM systems
9. Confirm that logging does not expose sensitive user data
10. Test that log volume is reasonable and does not impact browser performance
11. Verify that logs persist across browser restarts
12. Validate that disabled logging can be detected by monitoring systems

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

## 6.2 Extension System Security Assessments

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

- Chrome Content Script Isolated Worlds: https://developer.chrome.com/docs/extensions/mv3/content_scripts/#isolated_world
- Mozilla Content Script Execution Environment: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts#execution_environment
- 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:
   - 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
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 official extension stores
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, 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:
   - 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
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 (system information interfaces) 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 (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
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 web request interception API 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 browser internal or 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 an official extension store
2. Monitor the extension update process using browser internals (extension management interface, debugging tools)
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 extension package signature verification for the browser's package format
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 extension package 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 local and sync storage APIs:
   ```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:
   ```javascript
   browser.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 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
6. Test that extension storage persists across browser restarts
7. Verify that uninstalling an extension removes its storage
8. Test extension storage quota limits and enforcement
9. Verify that sync storage API has appropriate sync limits and encryption
10. Confirm that each extension has isolated storage inaccessible to other extensions
11. Verify that web pages cannot access any extension storage APIs or data
12. Check that extension storage persists across sessions but is removed on uninstall
13. Validate that storage quota limits are enforced per extension
14. Confirm that sync storage API uses encrypted sync when user is signed in
15. Verify that no file system or database tools can access extension storage from outside the browser
16. 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
2. Verify that background pages (persistent background scripts) are not allowed in Manifest V3
3. Test service worker lifecycle:
   - 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:
   - 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
6. Test that long-running operations should use alarms API or native messaging
7. Verify that service worker registration is automatic and cannot be modified
8. Test that service worker cannot be kept alive artificially
9. Verify CSP enforcement in service worker context
10. Confirm that Manifest V3 extensions use service workers, not persistent background pages
11. Verify that service workers terminate after idle timeout and restart on events
12. Check that DOM APIs are unavailable in service worker context
13. Validate that dynamic code execution is blocked in service workers
14. Confirm that service worker lifecycle is managed by the browser, not the extension
15. Verify that long-running tasks should use appropriate APIs (alarms, native messaging)
16. 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
2. Test that new extension submissions require Manifest V3 (check store policies)
3. Create test extensions demonstrating Manifest V3 security improvements:
   - 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:
   - 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
6. Test that Manifest V2 extensions show deprecation warnings
7. Verify manifest_version field validation (should be 2 or 3, with 3 preferred)
8. Test migration path from V2 to V3 with breaking changes properly surfaced
9. Confirm that browser fully supports Manifest V3 specification
10. Verify that Manifest V2 deprecated features are rejected in Manifest V3 extensions
11. Check that security improvements (service workers, declarativeNetRequest, strict CSP) are enforced
12. Validate that clear error messages guide developers away from deprecated patterns
13. Confirm that Manifest V2 extensions show deprecation warnings to users
14. Verify that extension stores enforce Manifest V3 for new submissions
15. Check that migration tooling and documentation are available

**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
2. Register the native messaging host according to platform requirements:
   - 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
4. Test communication between extension and native host using chrome.runtime.connectNative()
5. Verify that only extensions listed in native host manifest's allowed_origins can connect
6. Attempt connection from an unlisted extension and verify rejection
7. Test that native host path validation prevents directory traversal
8. Verify that native messaging requires user-installed native applications (not downloadable by extensions)
9. Test message size limits and validation
10. Verify that native host processes run with appropriate user privileges (not elevated)
11. Confirm that native messaging requires explicit nativeMessaging permission
12. Verify that native host manifest should acceptlist extension IDs in allowed_origins
13. Check that unlisted extensions cannot connect to native hosts
14. Validate that native host executable path is validated against tampering
15. Confirm that extensions cannot download or install native hosts programmatically
16. Verify that message passing is properly sandboxed and size-limited
17. Check that native hosts run without elevated privileges
18. 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:
   - 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
3. Test that extensions should declare host permissions for content script injection
4. Create a test extension that attempts to:
   - 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
6. Test that users are warned about extensions with broad host permissions during installation
7. Verify that content script modifications are visible in DevTools with extension attribution
8. Test that extensions cannot inject content into incognito mode without explicit permission
9. Verify CSP restrictions prevent content scripts from loading remote code
10. Confirm that content scripts require declared host permissions
11. Verify that browser UI pages and other extensions are protected from content script injection
12. Check that broad host permissions trigger prominent installation warnings
13. Validate that content script modifications are attributable in DevTools
14. Confirm that incognito mode requires explicit extension permission
15. Verify that CSP prevents content scripts from loading remote malicious code
16. 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
2. Monitor network traffic from the extension using browser DevTools or external proxy (e.g., Burp Suite, mitmproxy)
3. Verify that extensions cannot access browser telemetry or crash reporting APIs directly
4. Test that extension storage sync does not leak data to unauthorized parties
5. Verify that error reporting from extensions requires user consent if it includes:
   - 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
7. Verify that extensions should declare and justify data collection in privacy policies
8. Test that extensions cannot access browser's own telemetry data
9. Monitor for sensitive data leakage in extension console logs (passwords, tokens, PII)
10. Verify that extension store policies require privacy disclosures for data collection
11. Confirm that extensions have no access to browser telemetry APIs
12. Verify that extension-to-server communications are visible and monitorable by users
13. Check that sensitive user data is not included in extension error reports without consent
14. Validate that sync storage API data is encrypted and isolated
15. Confirm that extension developers shall disclose data collection practices
16. Verify that console logs do not inadvertently expose sensitive data
17. Check that users can review extension permissions related to data collection

**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
2. Inspect the extension package to verify signature presence
3. Use tools to verify the signature according to the browser's package format and signing infrastructure
4. Attempt to install a modified extension with:
   - Invalid signature
   - No signature
   - Expired signature
   - Signature from untrusted authority
5. Verify that the browser rejects all invalid signatures with clear error messages
6. Test that extensions loaded in developer mode can bypass signature requirements (but with clear warnings)
7. Verify that production extensions require valid signatures from trusted authorities
8. Test that signature validation occurs at both install time and runtime
9. Verify that browser checks certificate revocation for extension signatures
10. Test that extension updates have been signed by the same key as the original
11. Confirm that all production extensions have valid cryptographic signatures
12. Verify that signatures are verified at installation time
13. Check that invalid, expired, or missing signatures prevent installation
14. Validate that developer mode allows unsigned extensions with prominent warnings
15. Confirm that signature validation uses trusted certificate authorities
16. Verify that certificate revocation is checked during validation
17. Check that extension updates require signature continuity (same signing key)
18. 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:
   - 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
3. Verify that permission prompts:
   - 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
5. Verify that users can revoke permissions without uninstalling extension
6. Test optional permissions flow where extensions request additional permissions at runtime
7. Verify that permission grant/revocation is persistent across sessions
8. Test that permission changes trigger re-prompting for consent
9. Verify that extensions cannot request permissions programmatically without user interaction
10. Test that broad permissions like <all_urls> have prominent, scary warnings
11. Confirm that permission prompts use clear, user-friendly language (not technical jargon)
12. Verify that high-risk permissions have prominent warnings with specific explanations
13. Check that users can view all extension permissions in management UI