EN-304-617.md

   - Network operations outside of allowed extension APIs
   - Process creation or system command execution
   - Access to other processes' memory
3. Use platform-specific tools to verify sandbox restrictions: → Check that system command execution is prevented
   - Windows: Process Explorer to check process token and integrity level
   - macOS: Activity Monitor and sandbox-exec to check sandbox profile
   - Linux: /proc filesystem and seccomp to verify syscall restrictions
4. Verify that extension processes run with reduced privileges (low integrity on Windows, restricted sandbox on macOS/Linux) → Validate that extension processes have reduced privilege levels observable via platform tools
5. Test that native messaging hosts are the only permitted mechanism for system access → Confirm that native messaging is the only controlled pathway to system-level functionality
6. Verify that extension APIs providing system access (system information interfaces) are themselves sandboxed and permission-gated → Verify that process isolation prevents extensions from affecting each other or the browser
7. Test that renderer process crashes are isolated and don't affect browser stability → Check that sandbox violations trigger security errors and process termination

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

1. Install a test extension from an official extension store → Monitor network traffic to verify updates use HTTPS
2. Monitor the extension update process using browser internals (extension management interface, debugging tools) → Test that update checks include extension ID, version, and signature verification
3. Configure a local web server to serve a modified version of the extension with: → Confirm that all extension updates are downloaded over HTTPS
   - Invalid signature
   - Mismatched extension ID
   - Tampered CRX/XPI file
4. Attempt to force the browser to update from the malicious server → Verify that extension package file signatures are cryptographically verified before installation
5. Verify that the browser rejects the tampered update → Check that tampered updates are rejected with error messages
6. Test that update_url in manifest should point to official web stores for published extensions → Validate that extension ID shall match between installed extension and update
7. Verify that self-hosted extensions require proper signatures → Confirm that update URLs should be HTTPS and point to trusted sources
8. Test extension package signature verification for the browser's package format → Verify that self-hosted extensions require proper code signing

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

1. Attempt to access extension management interface through browser UI → Check that browser settings do not include extension-related configuration options
2. Verify that no extension installation options are available in menus or settings → Attempt to access extension APIs from web content or developer console
3. Attempt to navigate to extension store or marketplace URLs → Verify that extension APIs are undefined or throw errors
4. Verify that extension store pages are blocked or return error → Test that browser shortcuts and commands for extensions are disabled
5. Attempt to install an extension package file directly (drag-and-drop, file picker) → Verify that no extension-related processes or services are running
6. Verify that all installation attempts are rejected with clear messages → 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: → Verify that no extension content scripts can be injected into pages
   - 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 → Attempt to load background scripts or service workers for extensions
3. Test that extension-related protocol schemes return errors or are undefined → Confirm that all extension code execution paths are disabled
4. Attempt to load extension resources through fetch() or XMLHttpRequest → Test that browser does not maintain extension storage databases
5. Verify that all resource loading is rejected with clear error messages → Verify that extension-related directories do not exist or are inaccessible
6. Test that browser does not parse or validate extension manifest files → 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 → Verify that extension API bindings are not present in JavaScript engine
2. Use binary analysis tools to verify absence of extension subsystem code → Test that memory footprint is reduced compared to extension-enabled builds
3. Check that extension-related shared libraries are not included in installation → Check that browser about/version page indicates no extension support
4. Verify that browser configuration files contain no extension-related settings → Verify that security update notes do not include extension-related patches
5. Test that no extension-related resources (images, strings, UI elements) exist → Test that browser update mechanism does not fetch extension components
6. Inspect browser source code or build configuration to confirm conditional compilation → 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 → Test that enterprise policies cannot enable sideloading in EXT-1 mode
2. Verify that installation proceeds normally with appropriate permission prompts → Verify that users are informed why sideloading is disabled
3. Attempt to install extension from unofficial sources: → Test that extension update URLs point to official store
   - 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 → Verify that self-hosted extension updates are rejected
5. Test that developer mode is not available to enable sideloading → Check that browser UI provides clear guidance for installing extensions
6. Verify that command-line flags cannot bypass store restriction → 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 → Test that extensions can be reported for security issues post-publication
2. Verify that security review includes: → Verify that reported issues trigger re-review process
   - 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: → Check that extensions with security violations are removed from store
   - 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 → Verify that security review timeline is reasonable but not bypassable
5. Test that security review findings are communicated to developers → Test that updates also undergo security review
6. Verify that approved extensions display review status or badges → 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 → Verify that enterprise policies can prevent developer mode activation
2. Verify that developer mode is disabled by default → Test that re-enabling after disabling shows warning again
3. Verify that enabling developer mode requires multiple deliberate steps: → Verify that developer mode status is clearly indicated in browser UI
   - 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: → Test that users can easily disable developer mode
   - 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) → Verify that disabling developer mode offers to remove developer extensions
6. Test that developer mode cannot be enabled via command-line flags without user consent → 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 → Test that indicators cannot be hidden or disabled by extensions
2. Verify that developer extension displays visual indicator in extension management UI: → Verify that hovering over indicators explains developer mode risks
   - Special icon, badge, or label
   - Different color or styling
   - Explicit "Developer Mode" or "Unreviewed" text
3. Test that browser toolbar shows indicator when developer extensions are active → Test that new tab pages or security dashboards show developer extension warnings
4. Verify that extension icons have visual badges or overlays → Verify that indicators are visually distinct and noticeable
5. Test that browser status area shows developer mode indicator → Test that multiple developer extensions show cumulative warning
6. Verify that indicators persist across browser restarts → Confirm that disabling developer mode removes all indicators

**Pass Criteria**: Developer extensions have persistent visual indicators AND indicators appear in multiple locations AND indicators cannot be hidden AND indicators explain risks on interaction

**Fail Criteria**: No visual indicators exist OR indicators can be hidden OR indicators are too subtle OR no risk explanation available

**Evidence**: Screenshots of developer extension indicators in various UI locations, persistence test results, user visibility testing, indicator interaction demonstrations

**References**:

- Security Indicators Research: https://www.usenix.org/conference/soups2016/technical-sessions/presentation/felt
- Visual Security Warnings: https://dl.acm.org/doi/10.1145/3290605.3300516

### Assessment: EXT-REQ-26 (Developer mode update disablement)

**Reference**: EXT-2-REQ-8 - Developer mode shall disable automatic extension updates

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

**Task**: Verify that developer mode disables automatic extension updates to prevent developer extensions from silently updating to malicious code without user awareness, ensuring that developers have explicit control over extension versions during development and testing, and preventing attack scenarios where initial benign developer extension updates are replaced with malicious payloads through compromised update mechanisms or developer account takeovers.

**Verification**:

1. Install a developer mode extension with update_url in manifest → Verify that manual update option is available in UI
2. Verify that automatic updates are disabled for the developer extension → Test that manual updates require explicit user action
3. Test that browser does not check for updates automatically: → Verify that update disablement persists across browser restarts
   - Monitor network traffic for update check requests
   - Wait for normal update interval to pass
   - Verify no update checks occur
4. Publish a new version of the extension to the update URL → Test that store-installed extensions continue to receive automatic updates
5. Verify that the extension does not auto-update to new version → Verify that re-installing as store extension re-enables automatic updates
6. Test that extension management UI indicates updates are disabled → Check that extension update policy documentation explains developer mode behavior

**Pass Criteria**: Developer extensions do not auto-update AND no automatic update checks occur AND manual update option exists AND store extensions still update automatically

**Fail Criteria**: Developer extensions auto-update OR update checks occur automatically OR no manual update option OR store extensions lose updates

**Evidence**: Network traffic logs showing no update checks, extension version persistence tests, UI screenshots showing disabled auto-update, manual update flow demonstrations

**References**:

- Extension Update Security: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Updates
- Software Update Best Practices: https://csrc.nist.gov/publications/detail/sp/800-40/rev-4/final

### Assessment: EXT-REQ-27 (Developer mode activity logging)

**Reference**: EXT-2-REQ-9 - Browser shall log all developer mode extension activities

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

**Task**: Verify that the browser comprehensively logs all developer mode extension activities to provide visibility into potentially risky operations performed by unreviewed extensions, enabling security monitoring, incident investigation, and detection of malicious behavior, ensuring that security teams and advanced users can review what developer extensions are doing and identify suspicious patterns that may indicate compromise or abuse.

**Verification**:

1. Enable developer mode and install test developer extension → Test that log retention is appropriate for security analysis
2. Access browser logging interface (console, diagnostic logs, or audit logs) → Verify that logs can be exported or forwarded to monitoring systems
3. Trigger various developer extension activities: → Confirm that logging does not expose sensitive user data
   - Extension installation and loading
   - Permission requests and grants
   - API calls to sensitive interfaces
   - Network requests to external servers
   - Storage access and modifications
   - Content script injections
   - Background script execution
4. Verify that all activities are logged with sufficient detail: → Test that log volume is manageable and does not degrade performance
   - Timestamp of activity
   - Extension ID and name
   - Activity type and description
   - Resources or permissions accessed
   - Success or failure status
5. Test that logs include security-relevant events specifically → Verify that logs distinguish between developer and store extensions
6. Verify that logs are accessible to users and administrators → Check that critical security events trigger additional logging detail

**Pass Criteria**: All developer extension activities are logged AND logs contain sufficient detail for security analysis AND logs are accessible AND logging preserves user privacy

**Fail Criteria**: Activities are not logged OR log detail is insufficient OR logs are inaccessible OR logging exposes sensitive data

**Evidence**: Log excerpts showing various extension activities, log format and field documentation, export functionality demonstrations, privacy analysis of log content

**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: EXT-REQ-28 (Enterprise developer mode control)

**Reference**: EXT-2-REQ-10 - Enterprise policies shall be able to disable developer mode

**Given**: A conformant browser with EXT-2 capability in an enterprise environment

**Task**: Verify that enterprise administrators can completely disable developer mode through policy controls, preventing users from installing unreviewed extensions that could bypass corporate security controls, exfiltrate sensitive data, or compromise compliance requirements, ensuring that organizations can enforce extension security policies appropriate to their risk tolerance and regulatory obligations while still allowing use of approved store extensions.

**Verification**:

1. Access enterprise policy management interface or configuration system → Verify that all attempts to enable developer mode are blocked
2. Identify policy settings related to developer mode (e.g., DeveloperModeDisabled, ExtensionInstallSources) → Test that error messages clearly indicate policy restriction
3. Configure policy to disable developer mode → Verify that users cannot install developer extensions while policy is active
4. Deploy policy through enterprise management tools → Test that previously installed developer extensions are disabled or removed
5. Verify that developer mode toggle is hidden or disabled in browser UI → Verify that policy enforcement persists across browser restarts
6. Attempt to enable developer mode through all available methods: → Test that policy cannot be overridden by local user settings
   - Browser settings UI
   - Command-line flags
   - Configuration file modifications
   - Registry entries (Windows) or preference files

**Pass Criteria**: Enterprise policy can disable developer mode AND all bypass attempts fail AND policy enforcement is persistent AND users receive clear error messages

**Fail Criteria**: Developer mode can be enabled despite policy OR policy can be bypassed OR enforcement is inconsistent OR error messages are unclear

**Evidence**: Policy configuration screenshots, developer mode block demonstrations, policy status verification, audit log entries showing enforcement

**References**:

- Enterprise Browser Management: https://chromeenterprise.google/policies/
- Group Policy Configuration: https://docs.microsoft.com/en-us/deployedge/configure-microsoft-edge

### Assessment: EXT-REQ-29 (Sideloaded extension warnings)

**Reference**: EXT-3-REQ-9 - Sideloaded extensions shall display prominent security warnings

**Given**: A conformant browser with EXT-3 capability (unrestricted extension installation)

**Task**: Verify that sideloaded extensions (installed outside official stores) display prominent, persistent security warnings to inform users of increased risk, ensuring users understand that sideloaded extensions have not undergone official security review, may contain malicious code, and could compromise their privacy or security, enabling informed decisions about whether to continue using extensions from untrusted sources.

**Verification**:

1. Install a test extension via sideloading (direct file installation, not from store) → Test that warnings cannot be permanently dismissed or hidden
2. Verify that installation displays prominent security warning: → Verify that each browser session shows security status
   - Warning about unreviewed extension source
   - Explanation of potential security risks
   - Recommendation to only install trusted extensions
   - Option to cancel installation
3. Test that warning requires affirmative user acknowledgment → Test that extension permissions page emphasizes sideloaded status
4. Verify that installed sideloaded extension shows persistent indicators: → Verify that warning messages are clear and explain risks in user-friendly language
   - Visual badge or label in extension list
   - Warning icon on extension toolbar button
   - Status message in extension details
5. Test that browser status area indicates sideloaded extensions are present → Test that multiple sideloaded extensions show cumulative risk indicators
6. Verify that new tab page or security dashboard shows sideloaded extension warnings → Confirm that uninstalling sideloaded extension removes all warnings

**Pass Criteria**: Sideloaded extensions show prominent warnings at install AND persistent indicators remain visible AND warnings explain security risks clearly AND warnings cannot be hidden

**Fail Criteria**: No warnings shown OR warnings are dismissible OR risk explanation is unclear OR indicators are too subtle

**Evidence**: Installation warning screenshots, persistent indicator demonstrations, security dashboard views, warning message content analysis

**References**:

- Security Warning Effectiveness: https://www.usenix.org/conference/soups2013/proceedings/presentation/akhawe
- Extension Security Best Practices: https://extensionworkshop.com/documentation/develop/build-a-secure-extension/

### Assessment: EXT-REQ-30 (User extension permission controls)

**Reference**: EXT-3-REQ-10 - Browser shall provide user controls to review and revoke extension permissions

**Given**: A conformant browser with EXT-3 capability with installed extensions

**Task**: Verify that users have granular controls to review all granted extension permissions and revoke specific permissions without uninstalling extensions, enabling users to adjust extension access rights as their security preferences evolve, reducing over-privileged extensions, and providing a mechanism to contain potentially compromised extensions by limiting their access to sensitive APIs or data while investigating security concerns.

**Verification**:

1. Install test extensions with various permission sets → Verify that revoking permissions takes effect immediately
2. Access extension management interface → Test that extensions handle permission revocation gracefully (no crashes)
3. Verify that each extension displays complete list of granted permissions → Verify that revoked permissions persist across browser restarts
4. Test that permission list is organized and easy to understand: → Test that extensions can request re-grant of revoked permissions with user consent
   - Grouped by category (site access, API permissions, etc.)
   - Clear descriptions of what each permission enables
   - Visual indicators for high-risk permissions
5. Verify that users can revoke individual permissions through UI controls → Verify that permission changes are logged for user review
6. Test permission revocation for various permission types: → Test that revoking critical permissions triggers warning about potential extension breakage
   - Host permissions (site access)
   - API permissions (cookies, webRequest, etc.)
   - Optional permissions previously granted

**Pass Criteria**: All extension permissions are reviewable AND permissions can be individually revoked AND revocation is immediate and persistent AND extensions handle revocation gracefully

**Fail Criteria**: Permissions are not reviewable OR cannot be revoked individually OR revocation causes crashes OR changes do not persist

**Evidence**: Extension permission UI screenshots, permission revocation demonstrations, persistence tests, extension error handling logs, user control workflow recordings

**References**:

- Runtime Permissions: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/permissions
- User Control Principles: https://www.w3.org/TR/design-principles/#user-control

### Assessment: EXT-REQ-31 (Sideloaded extension malware scanning)

**Reference**: EXT-3-REQ-11 - Browser shall scan sideloaded extensions for known malware signatures

**Given**: A conformant browser with EXT-3 capability allowing sideloaded extensions

**Task**: Verify that the browser automatically scans sideloaded extensions for known malware signatures before installation, providing baseline protection against well-known malicious extensions even in unrestricted installation environments, detecting common malware families, cryptominers, data stealers, and other threats that have been previously identified and catalogued, reducing the risk of users inadvertently installing extensions with confirmed malicious behavior.

**Verification**:

1. Obtain or create test extension packages with known malware signatures: → Test that scan results are logged for security review
   - EICAR test file embedded in extension
   - Known malicious extension samples (from malware repositories)
   - Extensions with known cryptominer code
   - Extensions with data exfiltration patterns
2. Attempt to install each malicious test extension via sideloading → Verify that malware definitions are updated regularly
3. Verify that browser performs pre-installation malware scan → Test that scan performance does not significantly delay installation
4. Verify that malicious extensions are blocked before installation with clear warnings: → Verify that users are informed about scan process
   - Specific threat description (malware type detected)
   - Recommendation to not proceed
   - Option to report malicious extension
5. Test that scan covers all extension components: → Test that detected malware can be quarantined or deleted
   - JavaScript files
   - Background scripts and content scripts
   - Embedded libraries
   - WebAssembly modules
6. Verify that clean extensions pass scan and install normally → Confirm that scan cannot be disabled or bypassed by users

**Pass Criteria**: Malware scanning occurs before installation AND known malware is detected and blocked AND scan covers all extension components AND malware definitions are updated regularly

**Fail Criteria**: No malware scanning occurs OR known malware is not detected OR scan can be bypassed OR definitions are outdated

**Evidence**: Malware detection screenshots, scan log files, test results with various malware samples, malware definition update verification, performance impact analysis

**References**:

- Malware Detection in Browser Extensions: https://research.google/pubs/pub43824/
- Extension Security Analysis: https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/carlini

### Assessment: EXT-REQ-32 (Extension security event logging)

**Reference**: EXT-3-REQ-12 - All extension security events shall be logged for review

**Given**: A conformant browser with EXT-3 capability with extensions installed

**Task**: Verify that all extension security events are comprehensively logged to provide complete audit trail for security monitoring, incident response, and forensic analysis, enabling detection of malicious extension behavior, permission abuse, or security policy violations, ensuring that administrators and security teams have visibility into extension activities that could indicate compromise or misuse in environments with unrestricted extension installation.

**Verification**:

1. Install various test extensions (store, sideloaded, developer mode) → Test that logs are retained for appropriate security analysis period
2. Access browser security logging interface → Verify that logs can be exported or forwarded to SIEM systems
3. Trigger various extension security events: → Confirm that logging does not expose user passwords or sensitive personal data
   - Extension installation from different sources
   - Permission requests and grants/denials
   - Sensitive API usage (debugger, management, privacy)
   - Cross-extension communication attempts
   - Native messaging connections
   - WebRequest interception and modification
   - Suspicious network requests to unusual domains
   - Extension update installations
   - Extension crashes or security errors
   - User permission revocations
4. Verify that all events are logged with comprehensive details: → Test that high-severity events trigger immediate alerts or notifications
   - Timestamp with timezone
   - Extension ID, name, and version
   - Event type and severity level
   - User actions or automated triggers
   - Success/failure status
   - Affected resources (URLs, permissions, APIs)
   - Source of extension (store, sideloaded, developer)
5. Test that logs are structured for automated analysis (JSON, CSV, syslog format) → Verify that logs include contextual information for investigation
6. Verify that logs can be filtered by severity, extension, or event type → Test that log tampering is prevented or detected