EN-304-617.md.backup

- 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
14. Validate that users can revoke individual permissions without uninstalling
15. Confirm that optional permissions require explicit user interaction to grant
16. Verify that permission changes trigger new consent prompts
17. Check that broad permissions have special warnings about privacy implications
18. 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
2. Verify that no extension installation options are available in menus or settings
3. Attempt to navigate to extension store or marketplace URLs
4. Verify that extension store pages are blocked or return error
5. Attempt to install an extension package file directly (drag-and-drop, file picker)
6. Verify that all installation attempts are rejected with clear messages
7. Check that browser settings do not include extension-related configuration options
8. Attempt to access extension APIs from web content or developer console
9. Verify that extension APIs are undefined or throw errors
10. Test that browser shortcuts and commands for extensions are disabled
11. Verify that no extension-related processes or services are running
12. Check that browser help documentation does not reference extension features

**Pass Criteria**: No extension installation UI exists AND all installation attempts fail AND extension APIs are unavailable AND no extension-related processes run

**Fail Criteria**: Extension installation is possible through any method OR extension APIs are accessible OR extension UI elements exist

**Evidence**: Screenshots showing absence of extension UI, installation attempt rejection logs, API availability tests showing undefined extension APIs, process list showing no extension services

**References**:

- Browser Security Architecture: https://www.chromium.org/Home/chromium-security/
- Principle of Least Functionality: https://csrc.nist.gov/glossary/term/least_functionality

### Assessment: EXT-REQ-20 (Extension code loading prevention)

**Reference**: EXT-0-REQ-2 - Browser shall block all attempts to load extension code

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

**Task**: Verify that the browser actively blocks all attempts to load or execute extension code, preventing attackers from bypassing disabled extension UI through protocol handlers, file associations, or exploiting residual extension subsystem components, ensuring that the absence of extension support is enforced at the code execution level and cannot be circumvented through creative attack vectors.

**Verification**:

1. Attempt to load extension code through various vectors:
   - Direct file:// URL to extension directory
   - Custom protocol handlers (chrome-extension://, moz-extension://)
   - JavaScript injection attempting to load extension scripts
   - Browser command-line flags attempting to enable extensions
2. Verify that all code loading attempts are blocked at the engine level
3. Test that extension-related protocol schemes return errors or are undefined
4. Attempt to load extension resources through fetch() or XMLHttpRequest
5. Verify that all resource loading is rejected with clear error messages
6. Test that browser does not parse or validate extension manifest files
7. Verify that no extension content scripts can be injected into pages
8. Attempt to load background scripts or service workers for extensions
9. Confirm that all extension code execution paths are disabled
10. Test that browser does not maintain extension storage databases
11. Verify that extension-related directories do not exist or are inaccessible
12. Check that no extension code is present in browser installation

**Pass Criteria**: All extension code loading attempts are blocked AND extension protocols are undefined AND no extension scripts can execute AND no extension storage exists

**Fail Criteria**: Extension code can be loaded through any vector OR extension protocols function OR extension scripts execute

**Evidence**: Code loading attempt logs showing blocks, protocol scheme test results, resource loading rejection evidence, file system inspection showing no extension directories

**References**:

- Content Security Policy: https://www.w3.org/TR/CSP/
- Web Security Model: https://www.w3.org/Security/wiki/Same_Origin_Policy

### Assessment: EXT-REQ-21 (Extension subsystem removal)

**Reference**: EXT-0-REQ-3 - Browser build shall not include extension subsystem components

**Given**: A conformant browser with EXT-0 capability built without extension support

**Task**: Verify that the browser build completely excludes extension subsystem components at compile time, reducing binary size, eliminating potential vulnerabilities in unused code, and ensuring that extension support cannot be enabled through configuration changes or exploits, providing defense-in-depth by removing the entire extension attack surface rather than merely disabling it.

**Verification**:

1. Inspect browser binary for extension-related symbols or libraries
2. Use binary analysis tools to verify absence of extension subsystem code
3. Check that extension-related shared libraries are not included in installation
4. Verify that browser configuration files contain no extension-related settings
5. Test that no extension-related resources (images, strings, UI elements) exist
6. Inspect browser source code or build configuration to confirm conditional compilation
7. Verify that extension API bindings are not present in JavaScript engine
8. Test that memory footprint is reduced compared to extension-enabled builds
9. Check that browser about/version page indicates no extension support
10. Verify that security update notes do not include extension-related patches
11. Test that browser update mechanism does not fetch extension components
12. Confirm that build variant name or version indicates no extension support

**Pass Criteria**: Binary contains no extension code AND no extension libraries exist AND memory footprint is reduced AND build clearly indicates no extension support

**Fail Criteria**: Extension code exists in binary OR extension libraries are present OR extension support can be enabled through configuration

**Evidence**: Binary analysis reports, library dependency lists, build configuration excerpts, memory usage comparisons, version information showing build variant

**References**:

- Secure Software Development: https://csrc.nist.gov/projects/ssdf
- Attack Surface Reduction: https://www.microsoft.com/en-us/security/blog/topic/attack-surface-reduction/

### Assessment: EXT-REQ-22 (Official extension store restriction)

**Reference**: EXT-1-REQ-13 - Browser shall only allow installation from official curated store

**Given**: A conformant browser with EXT-1 capability (curated extension store only)

**Task**: Verify that the browser restricts extension installation exclusively to official curated stores, preventing sideloading of unreviewed extensions that could contain malware, spyware, or malicious code, ensuring that all installed extensions have undergone security review and comply with store policies, protecting users from supply chain attacks and compromised extension packages distributed through unofficial channels.

**Verification**:

1. Attempt to install an extension from the official curated store
2. Verify that installation proceeds normally with appropriate permission prompts
3. Attempt to install extension from unofficial sources:
   - Direct .crx/.xpi file installation
   - Drag-and-drop extension package
   - Installation via file:// URL
   - Third-party extension marketplaces
4. Verify that all unofficial installation attempts are blocked with clear error messages
5. Test that developer mode is not available to enable sideloading
6. Verify that command-line flags cannot bypass store restriction
7. Test that enterprise policies cannot enable sideloading in EXT-1 mode
8. Verify that users are informed why sideloading is disabled
9. Test that extension update URLs point to official store
10. Verify that self-hosted extension updates are rejected
11. Check that browser UI provides clear guidance for installing extensions
12. Confirm that all installed extensions show official store provenance

**Pass Criteria**: Only official store installation succeeds AND all sideloading is blocked AND no bypass mechanisms exist AND clear user messaging explains restrictions

**Fail Criteria**: Sideloading is possible through any method OR developer mode enables bypasses OR policy overrides exist OR error messages are unclear

**Evidence**: Official store installation success logs, sideloading attempt rejection screenshots, policy configuration tests, extension management UI showing store attribution

**References**:

- Extension Store Policies: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/AMO/Policy
- Supply Chain Security: https://csrc.nist.gov/projects/supply-chain-risk-management

### Assessment: EXT-REQ-23 (Extension security review requirement)

**Reference**: EXT-1-REQ-14 - Extensions shall undergo security review before store publication

**Given**: A conformant browser with EXT-1 capability and access to official extension store

**Task**: Verify that all extensions available in the official curated store have undergone security review before publication, ensuring that automated and manual security checks have identified and prevented malicious code, policy violations, or security vulnerabilities from reaching end users, providing assurance that installed extensions meet minimum security standards and comply with platform policies.

**Verification**:

1. Review extension store security review policies and procedures
2. Verify that security review includes:
   - Automated malware scanning
   - Static code analysis for security issues
   - Permission analysis and justification review
   - Manual code review for suspicious patterns
   - Privacy policy and data handling review
3. Attempt to submit a test extension with known security issues:
   - Excessive permissions without justification
   - Code obfuscation or minification violations
   - Data exfiltration to third-party servers
   - Suspicious API usage patterns
4. Verify that submission is rejected with specific feedback
5. Test that security review findings are communicated to developers
6. Verify that approved extensions display review status or badges
7. Test that extensions can be reported for security issues post-publication
8. Verify that reported issues trigger re-review process
9. Check that extensions with security violations are removed from store
10. Verify that security review timeline is reasonable but not bypassable
11. Test that updates also undergo security review
12. Confirm that review standards are publicly documented

**Pass Criteria**: All extensions undergo security review AND review includes automated and manual checks AND malicious submissions are rejected AND review standards are documented

**Fail Criteria**: Security review can be bypassed OR review is insufficient OR malicious extensions are published OR standards are not disclosed

**Evidence**: Store policy documentation, test submission rejection reports, security review process descriptions, malicious extension removal examples, review timeline data

**References**:

- Extension Review Guidelines: https://extensionworkshop.com/documentation/publish/add-on-policies/
- Secure Development Lifecycle: https://www.microsoft.com/en-us/securityengineering/sdl/

### Assessment: EXT-REQ-24 (Developer mode activation security)

**Reference**: EXT-2-REQ-6 - Developer mode shall require explicit user activation with security warnings

**Given**: A conformant browser with EXT-2 capability (curated store with developer mode)

**Task**: Verify that developer mode requires explicit, informed user activation with clear security warnings, preventing malicious actors from tricking users into enabling developer mode through social engineering, ensuring that users understand the security implications of allowing unreviewed extension code, and providing appropriate warnings about the increased risk of installing extensions that have not undergone official security review.

**Verification**:

1. Attempt to enable developer mode through browser settings
2. Verify that developer mode is disabled by default
3. Verify that enabling developer mode requires multiple deliberate steps:
   - Navigating to advanced settings section
   - Clicking explicit "Enable Developer Mode" toggle or button
   - Acknowledging security warning dialog
4. Test that security warning explains risks clearly:
   - Extensions in developer mode are not reviewed
   - Potential for malicious code execution
   - Risk of data theft or browser compromise
   - Recommendation to only use for development purposes
5. Verify that warning requires affirmative user action (not auto-dismiss)
6. Test that developer mode cannot be enabled via command-line flags without user consent
7. Verify that enterprise policies can prevent developer mode activation
8. Test that re-enabling after disabling shows warning again
9. Verify that developer mode status is clearly indicated in browser UI
10. Test that users can easily disable developer mode
11. Verify that disabling developer mode offers to remove developer extensions
12. Check that developer mode state persists across browser restarts with clear indicators

**Pass Criteria**: Developer mode is disabled by default AND requires explicit multi-step activation AND shows clear security warnings AND enterprise policies can restrict activation

**Fail Criteria**: Developer mode is easy to enable accidentally OR warnings are unclear OR can be bypassed OR no policy controls exist

**Evidence**: Developer mode activation flow screenshots, security warning dialog content, policy configuration tests, UI state indicators

**References**:

- User Security Awareness: https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html
- Security Warning Design: https://www.usenix.org/conference/soups2020/presentation/reeder

### Assessment: EXT-REQ-25 (Developer mode visual indicators)

**Reference**: EXT-2-REQ-7 - Developer mode extensions shall display persistent visual indicators

**Given**: A conformant browser with EXT-2 capability with developer mode enabled

**Task**: Verify that extensions loaded in developer mode display persistent, prominent visual indicators to continuously remind users that unreviewed code is running in their browser, enabling users to distinguish between vetted store extensions and potentially risky developer extensions, and providing visual cues that can help users identify when developer mode may have been enabled without their knowledge or when they should reconsider the security of their browser configuration.

**Verification**:

1. Enable developer mode and install test developer extension
2. Verify that developer extension displays visual indicator in extension management UI:
   - Special icon, badge, or label
   - Different color or styling