EN-304-617.md

1. Review the permission model for the JavaScript bridge
2. Verify that permissions can be granted at individual API level rather than all-or-nothing
3. Test different permission configurations: grant some APIs but deny others to the same origin
4. Verify that capability tokens or permissions can be scoped by origin, time, or usage count
5. Test that temporary permissions expire correctly
6. Verify that permission grants are logged with full context
7. Test that users or administrators can configure granular permissions
8. Verify that the principle of least privilege is enforced by default
9. Permission system supports individual API-level grants
10. Different origins can have different permission sets
11. Permissions can be scoped by time, usage count, or other constraints
12. Temporary permissions expire as configured
13. Permission grants and revocations are logged
14. Users/administrators have control over granular permissions
15. Default configuration follows least-privilege principle
16. Permission model is clearly documented

**Pass Criteria**: Granular per-API permissions are supported AND permissions are properly scoped AND least-privilege is enforced by default

**Fail Criteria**: Only all-or-nothing permissions exist OR no permission scoping is available OR overly permissive defaults

**Evidence**: Permission configuration files, permission model documentation, test results showing granular control, user/admin permission management interface screenshots, audit logs

**References**:

- Capability-Based Security: https://en.wikipedia.org/wiki/Capability-based_security
- Principle of Least Privilege (NIST): https://csrc.nist.gov/glossary/term/least_privilege
- W3C Permissions API: https://www.w3.org/TR/permissions/
- Android Permission Model: https://developer.android.com/guide/topics/permissions/overview

### Assessment: EMB-REQ-12 (Storage isolation from host)

**Reference**: EMB-REQ-12 - Embedded browsers shall isolate storage (cookies, localStorage, IndexedDB) from the host application's native storage

**Given**: A conformant embedded browser (EMB-0 or higher)

**Task**: Storage isolation between embedded browsers and host applications prevents data leakage attacks where malicious web content attempts to access sensitive application data stored in native storage mechanisms. Without proper isolation, compromised web content could read authentication tokens from host storage, modify application configuration data, or exfiltrate user information. Storage namespace collisions could also enable web content to poison host application data, leading to privilege escalation or application malfunction. Proper isolation ensures that the web security model and native application security model remain separate and cannot be used to undermine each other.

**Verification**:

1. Store data in the host application's native storage (SharedPreferences, UserDefaults, native database)
2. Load web content and attempt to access host storage through web APIs (localStorage, IndexedDB, cookies)
3. Verify that web content cannot read native host storage
4. Store data in web content storage and attempt to access it from host application
5. Verify that host application code cannot directly access web storage without explicit bridge APIs
6. Test that different embedded browser instances have isolated storage
7. Verify that clearing host application data does not affect web storage (unless explicitly configured)
8. Test that malicious web content cannot pollute host storage namespace
9. Web content storage (localStorage, IndexedDB, cookies) is isolated from host native storage
10. Host native storage is not accessible from web APIs
11. Web storage is not directly accessible from host code (without explicit bridge)
12. Multiple embedded browser instances have independent storage
13. Storage isolation is maintained even for same-origin content in different instances
14. Storage clearing operations are properly scoped
15. No namespace collisions between web and native storage

**Pass Criteria**: Complete storage isolation between web content and host application AND no cross-contamination is possible

**Fail Criteria**: Web content can access host storage OR host can access web storage without proper APIs OR storage namespaces collide

**Evidence**: Code review of storage isolation implementation, test results showing blocked access attempts, storage dump comparisons, penetration test results

**References**:

- Android WebView Data Storage: https://developer.android.com/reference/android/webkit/WebView#getDataDir()
- Chromium Embedded Framework Storage Isolation: https://bitbucket.org/chromiumembedded/cef/wiki/GeneralUsage
- Web Storage API: https://html.spec.whatwg.org/multipage/webstorage.html

### Assessment: EMB-REQ-13 (CSP enforcement for embedded content)

**Reference**: EMB-REQ-13 - Host applications shall implement Content Security Policy (CSP) enforcement for all embedded web content

**Given**: A conformant embedded browser (EMB-1 or higher)

**Task**: Content Security Policy enforcement for embedded web content provides defense-in-depth protection against XSS attacks, malicious script injection, and unauthorized resource loading that could be used to exfiltrate data or establish command-and-control channels. Without CSP, compromised or malicious web content can inject inline scripts, load external malicious resources, or use eval() to execute attacker-controlled code. Host-configured CSP ensures that even if web content is compromised, the attack surface is constrained by preventing dangerous JavaScript patterns and restricting where content can be loaded from.

**Verification**:

1. Configure the embedded browser with a restrictive CSP policy
2. Load web content and verify CSP is enforced: inline scripts blocked, external resource loading restricted
3. Test that CSP violations trigger browser console errors and violation reports
4. Verify that CSP cannot be bypassed by web content
5. Test that meta tag CSPs are respected but cannot weaken configured policy
6. Verify that CSP applies to all content including iframes
7. Test CSP report-uri or report-to functionality
8. Verify that host application can configure CSP policy programmatically
9. CSP policy is configurable by host application
10. CSP is enforced for all embedded web content
11. Inline scripts, eval, and other dangerous features are blocked per policy
12. CSP violations generate console errors and reports
13. Web content cannot bypass or weaken CSP policy
14. CSP applies to all nested contexts (iframes)
15. Violation reports are sent to configured endpoints
16. Default CSP is restrictive following security best practices

**Pass Criteria**: Host-configured CSP is enforced for all content AND violations are reported AND policy cannot be bypassed

**Fail Criteria**: CSP is not enforced OR can be bypassed OR violations are not reported

**Evidence**: CSP configuration code, browser console showing CSP violations, violation report logs, test results demonstrating CSP enforcement, penetration test results

**References**:

- Content Security Policy Level 3: https://www.w3.org/TR/CSP3/
- CSP Best Practices (OWASP): https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
- Android WebView CSP: https://developer.android.com/reference/android/webkit/WebSettings#setMixedContentMode(int)
- iOS WKWebView CSP Support: https://webkit.org/blog/7929/content-security-policy-for-webkit/

### Assessment: EMB-REQ-14 (Encrypted cross-process bridge)

**Reference**: EMB-REQ-14 - JavaScript bridge communications shall be encrypted when crossing process boundaries

**Given**: A conformant embedded browser with multi-process architecture (EMB-2 or higher)

**Task**: Encrypted cross-process bridge communications protect against local privilege escalation attacks where a malicious process on the same system attempts to intercept or tamper with JavaScript bridge messages passing between the browser process and host application process. Without encryption, attackers with local access could use debugging tools, IPC monitoring utilities, or memory inspection to capture sensitive bridge data including authentication tokens, API parameters, or user data. Message integrity protection prevents tampering attacks, while anti-replay mechanisms prevent attackers from capturing and reusing legitimate bridge messages to perform unauthorized operations.

**Verification**:

1. Identify whether the embedded browser uses a multi-process architecture
2. Verify that JavaScript bridge messages cross process boundaries
3. Analyze inter-process communication (IPC) mechanisms used for bridge messages
4. Verify that IPC channels are encrypted or use secure transport
5. Attempt to intercept bridge messages using debugging tools or IPC monitoring
6. Verify that message integrity is protected (authentication, MACs)
7. Test that replay attacks are prevented (nonces, sequence numbers)
8. Verify that encryption keys are securely managed and rotated
9. Multi-process architecture uses encrypted IPC for bridge messages
10. Bridge messages are not observable in plaintext during IPC
11. Message integrity is cryptographically protected
12. Replay attacks are prevented through anti-replay mechanisms
13. Encryption keys are properly generated and managed
14. IPC interception does not reveal sensitive bridge data
15. Encryption meets current cryptographic standards (AES-256, authenticated encryption)

**Pass Criteria**: Bridge IPC is encrypted AND integrity-protected AND replay-protected when crossing process boundaries

**Fail Criteria**: Plaintext bridge messages observable in IPC OR no integrity protection OR replay attacks possible

**Evidence**: Architecture documentation showing multi-process design, IPC traces showing encrypted messages, code review of encryption implementation, penetration test results, cryptographic audit reports

**References**:

- Chromium Mojo IPC Security: https://chromium.googlesource.com/chromium/src/+/master/mojo/README.md
- Electron IPC Security: https://www.electronjs.org/docs/latest/tutorial/ipc
- NIST SP 800-52: TLS Guidelines: https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final
- CWE-319: Cleartext Transmission of Sensitive Information: https://cwe.mitre.org/data/definitions/319.html

### Assessment: EMB-REQ-15 (Native UI overlay prevention)

**Reference**: EMB-REQ-15 - Embedded browsers shall prevent web content from triggering native UI overlays or permission prompts that could mislead users

**Given**: A conformant embedded browser (EMB-1 or higher)

**Task**: Native UI overlay prevention protects users from social engineering attacks where malicious web content attempts to display fake permission prompts, system dialogs, or security warnings that appear to originate from the operating system or host application. Without proper controls, attackers can create convincing spoofed UI elements to trick users into granting permissions, entering credentials, or taking dangerous actions. Preventing web content from triggering misleading native UI and ensuring clear origin identification helps users make informed trust decisions and prevents clickjacking attacks that overlay malicious content on top of legitimate security prompts.

**Verification**:

1. Attempt to trigger native UI elements from web content: system dialogs, permission prompts, notifications
2. Verify that all UI elements clearly identify their source (host app vs. web content)
3. Test that web content cannot create UI elements that appear to be from the OS or host app
4. Attempt clickjacking attacks using iframes and native UI
5. Verify that permission prompts clearly show the requesting origin
6. Test that web content cannot programmatically trigger permission prompts in rapid succession
7. Verify that native UI elements cannot be overlaid or obscured by web content
8. Test that fullscreen mode does not hide native UI security indicators
9. Web content cannot trigger misleading native UI elements
10. All UI clearly indicates whether it originates from web content or host/OS
11. Permission prompts show the requesting origin clearly
12. Clickjacking attempts are prevented by UI design
13. Rapid permission prompt abuse is prevented
14. Native security indicators cannot be hidden or spoofed
15. Fullscreen mode maintains critical security UI
16. Users can distinguish web content UI from native UI

**Pass Criteria**: Web content cannot trigger misleading native UI AND all prompts clearly show origin AND security indicators are protected

**Fail Criteria**: Misleading UI can be triggered OR origin is not clear OR security indicators can be hidden

**Evidence**: Screenshots of UI elements showing origin indicators, test results of UI spoofing attempts, clickjacking test results, user study results on UI clarity, security audit reports

**References**:

- OWASP Clickjacking Defense: https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html
- Android UI Security: https://developer.android.com/topic/security/risks/tapjacking
- CWE-1021: Improper Restriction of Rendered UI Layers: https://cwe.mitre.org/data/definitions/1021.html

### Assessment: EMB-REQ-16 (API surface allowlisting over denylisting)

**Reference**: EMB-REQ-16 - Host applications shall implement allowlists for JavaScript bridge API surface rather than denylists

**Given**: A conformant embedded browser with JavaScript bridge (EMB-1 or higher)

**Task**: Allowlist-based API surface control is critical for preventing unauthorized access to internal APIs that were never intended for web content exposure. Denylist approaches are inherently insecure because they require developers to anticipate and block every dangerous API, while inevitably missing newly added functionality or overlooking indirect access paths. With allowlisting, only explicitly registered APIs are accessible, ensuring that refactoring, new feature development, or internal API additions cannot accidentally expand the attack surface. This prevents attackers from discovering and exploiting unintended API endpoints through reflection, code analysis, or brute-force enumeration.

**Verification**:

1. Review the JavaScript bridge implementation to determine if it uses allowlist or denylist approach
2. Verify that only explicitly registered APIs are accessible (allowlist approach)
3. Attempt to discover and call APIs that are not in the allowlist
4. Test that new APIs require explicit registration before becoming accessible
5. Verify that the absence of an API from a denylist does not make it accessible
6. Review code to confirm allowlist-based access control logic
7. Test that reflection or introspection cannot enumerate unlisted APIs
8. Verify that the allowlist is the sole source of truth for API accessibility
9. JavaScript bridge uses allowlist-based access control
10. Only explicitly allowlisted APIs are accessible from web content
11. APIs not in allowlist are not accessible regardless of denylist status
12. New APIs require explicit allowlist registration
13. Denylists (if present) are used only as an additional layer, not primary control
14. Reflection/introspection cannot discover non-allowlisted APIs
15. Code review confirms allowlist-first architecture
16. Security documentation clearly describes allowlist approach

**Pass Criteria**: Allowlist-based access control is implemented AND only allowlisted APIs are accessible AND denylisting is not the primary control

**Fail Criteria**: Denylist-based access control is used as primary mechanism OR non-allowlisted APIs are accessible

**Evidence**: Code review showing allowlist implementation, security architecture documentation, test results showing blocked non-allowlisted API access, API registration procedures

**References**:

- OWASP Access Control: https://cheatsheetseries.owasp.org/cheatsheets/Access_Control_Cheat_Sheet.html
- Allowlist vs Denylist Best Practices: https://owasp.org/www-community/vulnerabilities/Improper_Data_Validation
- CWE-183: Permissive List of Allowed Inputs: https://cwe.mitre.org/data/definitions/183.html
- Electron Context Bridge Allowlisting: https://www.electronjs.org/docs/latest/api/context-bridge

### Assessment: EMB-REQ-17 (Certificate validation for remote content)

**Reference**: EMB-REQ-17 - Embedded browsers shall validate SSL/TLS certificates for all remote content sources with certificate pinning for critical origins

**Given**: A conformant embedded browser loading remote content (EMB-1 or higher)

**Task**: Certificate validation and pinning for remote content protects against man-in-the-middle attacks where attackers intercept network traffic to inject malicious content into the embedded browser. Without proper certificate validation, attackers on compromised networks can present fraudulent certificates to serve malicious JavaScript that exploits bridge APIs or steals sensitive data. Certificate pinning for critical origins provides additional protection against certificate authority compromises and ensures that only the expected server certificates are trusted, preventing sophisticated attacks using rogue or compromised CAs to issue valid but malicious certificates for trusted domains.

**Verification**:

1. Configure the embedded browser to load content from HTTPS origins
2. Attempt to load content from a server with an invalid certificate (expired, self-signed, wrong hostname)
3. Verify that certificate validation errors block content loading
4. Test that user/host cannot bypass certificate errors for critical origins
5. Configure certificate pinning for critical origins used by the application
6. Attempt to use a valid but non-pinned certificate for a pinned origin
7. Verify that pinning violations block content loading and trigger alerts
8. Test that certificate transparency information is validated
9. Verify that pin backups exist to prevent lockout
10. All HTTPS content undergoes full certificate validation
11. Invalid certificates block content loading
12. Certificate errors generate clear error messages and logs
13. Certificate pinning is enforced for configured critical origins
14. Pinning violations prevent content loading and trigger security events
15. Backup pins exist to allow pin rotation without lockout
16. Certificate Transparency validation is performed
17. No user/host bypass options for certificate errors on critical origins

**Pass Criteria**: Full certificate validation is enforced AND certificate pinning works for critical origins AND no bypasses exist for pinned origins

**Fail Criteria**: Certificate validation can be bypassed OR pinning is not enforced OR no backup pins exist

**Evidence**: Certificate validation test results, pinning configuration, test results with invalid certificates, security logs showing validation failures, Certificate Transparency logs

**References**:

- RFC 6797: HTTP Strict Transport Security (HSTS): https://datatracker.ietf.org/doc/html/rfc6797
- OWASP Certificate Pinning: https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
- Android Network Security Config: https://developer.android.com/training/articles/security-config
- iOS App Transport Security: https://developer.apple.com/documentation/security/preventing_insecure_network_connections
- RFC 6962: Certificate Transparency: https://datatracker.ietf.org/doc/html/rfc6962

### Assessment: EMB-REQ-18 (Trusted origin allowlisting)

**Reference**: EMB-REQ-18 - Host applications shall implement allowlists of trusted content origins and reject content from unapproved sources

**Given**: A conformant embedded browser (EMB-1 or higher)

**Task**: Trusted origin allowlisting prevents the embedded browser from loading malicious or untrusted content that could exploit JavaScript bridge APIs or compromise user data. Without origin restrictions, the browser could be tricked into loading attacker-controlled content through phishing links, open redirects, or DNS rebinding attacks. Enforcing a strict allowlist ensures that only vetted, trusted origins can execute in the privileged embedded browser context, preventing attackers from injecting malicious web pages that would have access to sensitive bridge functionality or user information intended only for legitimate application content.

**Verification**:

1. Review the host application's origin allowlist configuration
2. Attempt to load content from allowlisted origins and verify it loads successfully
3. Attempt to load content from non-allowlisted origins and verify it is blocked
4. Test redirect chains that exit allowlisted domains and verify they are blocked
5. Verify that allowlist enforcement applies to main frame, iframes, and XHR/fetch requests
6. Test that URL parameters or fragments cannot be used to bypass allowlist
7. Verify that allowlist configuration is immutable by web content
8. Test that allowlist violations trigger logging and security alerts
9. Origin allowlist is configured and documented
10. Only allowlisted origins can load in the embedded browser
11. Non-allowlisted origins are blocked with appropriate error messages
12. Redirect chains exiting allowlisted domains are blocked
13. Allowlist applies to all resource types and contexts
14. URL manipulation cannot bypass allowlist enforcement
15. Allowlist violations generate security events and logs
16. Users/administrators can configure the allowlist

**Pass Criteria**: Origin allowlist is enforced for all content AND violations are blocked and logged AND allowlist cannot be bypassed

**Fail Criteria**: Non-allowlisted origins can load OR allowlist can be bypassed OR violations not logged

**Evidence**: Origin allowlist configuration, test results with blocked non-allowlisted origins, security logs showing violations, redirect chain test results, penetration test reports

**References**:

- OWASP Content Security Policy: https://owasp.org/www-community/controls/Content_Security_Policy
- Android WebView URL Filtering: https://developer.android.com/reference/android/webkit/WebViewClient#shouldOverrideUrlLoading(android.webkit.WebView,%20android.webkit.WebResourceRequest)
- iOS WKNavigationDelegate: https://developer.apple.com/documentation/webkit/wknavigationdelegate
- CSP frame-ancestors directive: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors

### Assessment: EMB-REQ-19 (Subresource Integrity for external scripts)

**Reference**: EMB-REQ-19 - Embedded browsers shall enforce Subresource Integrity (SRI) for all external scripts loaded by trusted content

**Given**: A conformant embedded browser loading trusted content with external dependencies (EMB-2 or higher)

**Task**: Subresource Integrity enforcement protects against supply chain attacks where compromised CDNs or third-party script providers serve malicious code to embedded browsers. Without SRI, attackers who compromise external script sources can inject malicious JavaScript that would execute with full access to JavaScript bridge APIs and user data. SRI ensures that external scripts match their expected cryptographic hashes, preventing execution of modified or substituted content even if the hosting server is compromised, providing critical defense-in-depth protection for embedded browsers that load resources from external origins.

**Verification**:

1. Configure trusted content pages to load external scripts from CDNs
2. Add SRI integrity attributes to script tags: `<script src="..." integrity="sha384-..." crossorigin="anonymous">`
3. Verify that scripts with correct integrity hashes load successfully
4. Modify the external script content and verify that integrity validation fails and blocks execution
5. Attempt to load scripts without integrity attributes from external origins and verify policy enforcement
6. Test that integrity validation applies to CSS, scripts, and other subresources
7. Verify that SRI failures trigger console errors and CSP violation reports
8. Test that the host application can enforce SRI policy via CSP require-sri-for directive
9. SRI integrity checking is enforced for external scripts
10. Scripts with correct integrity hashes load and execute
11. Scripts with incorrect or missing hashes are blocked per policy
12. SRI violations generate console errors and logs
13. SRI applies to scripts, stylesheets, and other subresources
14. Host application can mandate SRI via CSP policy
15. Cryptographic hash algorithms used are secure (SHA-384, SHA-512)

**Pass Criteria**: SRI is enforced for external scripts AND integrity violations block resource loading AND policy can be mandated by host

**Fail Criteria**: SRI is not enforced OR can be bypassed OR weak hash algorithms are accepted

**Evidence**: HTML source showing SRI attributes, browser console showing integrity check results, test results with modified scripts, CSP headers mandating SRI, security logs

**References**:

- Subresource Integrity specification: https://www.w3.org/TR/SRI/
- SRI Best Practices (MDN): https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
- CSP require-sri-for: https://www.w3.org/TR/CSP3/#directive-require-sri-for
- OWASP Secure Headers Project: https://owasp.org/www-project-secure-headers/

### Assessment: EMB-REQ-20 (Certificate pinning with backup pins)

**Reference**: EMB-REQ-20 - Certificate pinning configurations shall include backup pins and pin rotation mechanisms to prevent lockout

**Given**: A conformant embedded browser with certificate pinning (EMB-2 or higher)

**Task**: Backup pins and pin rotation mechanisms are essential to prevent application lockout scenarios where certificate rotation or CA changes leave deployed applications unable to connect to pinned origins. Without backup pins, a single certificate expiration or key compromise could render all deployed applications non-functional until users install updates. Proper pin management with backup pins and documented rotation procedures ensures that certificate pinning provides strong security against MITM attacks while maintaining operational resilience, preventing scenarios where security controls inadvertently cause widespread application failures that force emergency unpinning and reduce overall security posture.

**Verification**:

1. Review certificate pinning configuration for all pinned origins
2. Verify that at least one backup pin exists for each pinned origin
3. Test that the primary pin is enforced correctly
4. Simulate primary certificate rotation and verify backup pin is accepted
5. Verify that pin rotation procedures are documented
6. Test that pin expiration dates are configured appropriately (not too distant future)
7. Verify that pin updates can be delivered to deployed applications
8. Test fallback behavior when all pins fail (should block, not fall back to unpinned)
9. Each pinned origin has at least one backup pin configured
10. Primary and backup pins are both enforced correctly
11. Certificate rotation can occur using backup pins without lockout
12. Pin rotation procedures are documented and tested
13. Pin expiration/rotation schedules are reasonable
14. Pin updates can be delivered via app updates or dynamic configuration
15. Total pin failure blocks connections rather than falling back to no pinning
16. Pins include Subject Public Key Info (SPKI) hashes, not just certificates

**Pass Criteria**: Backup pins exist for all pinned origins AND pin rotation is supported AND lockout scenarios are prevented

**Fail Criteria**: No backup pins exist OR pin rotation is not supported OR lockout is possible OR insecure fallback behavior

**Evidence**: Certificate pinning configuration files, pin backup documentation, pin rotation test results, pin expiration monitoring, security architecture documentation

**References**:

- OWASP Certificate Pinning Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html
- RFC 7469: Public Key Pinning Extension for HTTP: https://datatracker.ietf.org/doc/html/rfc7469
- Android Network Security Config - Pin Backup: https://developer.android.com/training/articles/security-config#CertificatePinning
- iOS Certificate Pinning Best Practices: https://developer.apple.com/news/?id=g9ejcf8y

### Assessment: EMB-REQ-21 (Mixed content prevention)

**Reference**: EMB-REQ-21 - Embedded browsers shall prevent mixed content (HTTPS pages loading HTTP resources) in all configurations

**Given**: A conformant embedded browser (EMB-1 or higher)

**Task**: Mixed content prevention protects against downgrade attacks where attackers intercept insecure HTTP resources loaded by HTTPS pages to inject malicious code or steal sensitive data. Even a single HTTP script loaded by an HTTPS page undermines the entire security model, allowing network attackers to execute arbitrary JavaScript with full access to the page's privileges and JavaScript bridge APIs. Blocking mixed content ensures that the security guarantees of HTTPS connections cannot be bypassed through insecure subresources, preventing attackers from using unencrypted channels to compromise otherwise secure embedded browser sessions.

**Verification**:

1. Load an HTTPS page in the embedded browser
2. Attempt to load HTTP subresources from the HTTPS page: images, scripts, stylesheets, XHR, fetch
3. Verify that passive mixed content (images, media) is blocked or triggers warnings
4. Verify that active mixed content (scripts, stylesheets, iframes) is always blocked
5. Test that mixed content blocking cannot be disabled by web content
6. Verify that host application cannot weaken mixed content protection
7. Test that browser console shows clear mixed content errors
8. Verify that CSP upgrade-insecure-requests directive is supported
9. Active mixed content is always blocked
10. Passive mixed content is blocked or triggers prominent warnings
11. Mixed content errors appear in browser console with details
12. Web content cannot disable mixed content protection
13. Host application cannot weaken mixed content blocking
14. upgrade-insecure-requests CSP directive automatically upgrades HTTP to HTTPS
15. No configuration option exists to allow mixed content on HTTPS pages

**Pass Criteria**: Active mixed content is always blocked AND passive mixed content protection is enforced AND cannot be disabled

**Fail Criteria**: Mixed content loads successfully OR protection can be disabled OR insufficient warnings

**Evidence**: Browser console showing mixed content errors, test results with blocked HTTP resources, CSP header analysis, security configuration review, network traffic captures

**References**:

- W3C Mixed Content specification: https://www.w3.org/TR/mixed-content/
- Mixed Content (MDN): https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content
- CSP upgrade-insecure-requests: https://www.w3.org/TR/upgrade-insecure-requests/
- Chromium Mixed Content Policy: https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins

### Assessment: EMB-REQ-22 (Trust decision logging)

**Reference**: EMB-REQ-22 - Trust decisions shall be logged with sufficient detail to detect trust boundary violations

**Given**: A conformant embedded browser with trust management (EMB-1 or higher)

**Task**: Trust decision logging is critical for detecting and investigating attacks that attempt to cross trust boundaries in embedded browsers, such as untrusted origins trying to access privileged JavaScript bridge APIs or certificate validation bypasses. Without comprehensive logging of trust decisions, security teams cannot identify patterns of attack attempts, investigate security incidents, or detect compromised trusted origins that begin exhibiting suspicious behavior. Detailed trust logs enable security monitoring systems to flag anomalies like repeated origin allowlist violations, certificate pinning failures, or unusual patterns of bridge API access that may indicate reconnaissance or active exploitation attempts.

**Verification**:

1. Configure logging for trust-related decisions in the embedded browser
2. Load content from trusted and untrusted origins
3. Review logs and verify they contain: origin, timestamp, trust decision outcome, reason for decision
4. Attempt trust boundary violations (untrusted origin accessing privileged APIs)
5. Verify that violations are logged with full context
6. Test that certificate validation decisions are logged
7. Verify that origin allowlist enforcement is logged
8. Test that logs are stored securely and cannot be tampered with by web content
9. Verify log retention policies for security-relevant events
10. All trust decisions are logged with sufficient detail
11. Logs include origin, timestamp, decision, and rationale
12. Trust boundary violations are logged with full context
13. Certificate validation results are logged
14. Origin allowlist enforcement is logged
15. Logs are protected from tampering
16. Log retention balances security needs and privacy
17. Logs are accessible for security monitoring and incident response

**Pass Criteria**: All trust decisions are logged with sufficient detail AND violations are logged AND logs are tamper-protected

**Fail Criteria**: Trust decisions are not logged OR insufficient detail OR logs can be tampered with

**Evidence**: Log samples showing trust decisions, log configuration documentation, test results showing violation logging, log integrity verification, log retention policy documentation

**References**:

- OWASP Logging Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
- NIST SP 800-92: Guide to Computer Security Log Management: https://csrc.nist.gov/publications/detail/sp/800-92/final
- CWE-778: Insufficient Logging: https://cwe.mitre.org/data/definitions/778.html

### Assessment: EMB-REQ-23 (Cryptographic signature verification for local content)

**Reference**: EMB-REQ-23 - Embedded browsers loading local/bundled content shall verify cryptographic signatures before execution

**Given**: A conformant embedded browser loading bundled/local content (EMB-2 or higher)

**Task**: Cryptographic signature verification for local content protects against tampering attacks where attackers with file system access attempt to modify bundled HTML, JavaScript, or CSS files to inject malicious code. Without signature verification, local privilege escalation or compromised backup/restore processes could allow attackers to silently modify embedded browser content that executes with full JavaScript bridge API access. Digital signatures ensure content integrity from build time through deployment, detecting any unauthorized modifications and preventing execution of tampered local resources that could otherwise compromise the entire host application through bridge exploitation.

**Verification**:

1. Identify local/bundled content loaded by the embedded browser (HTML, JS, CSS files)
2. Verify that all bundled content is cryptographically signed
3. Review signature verification implementation in the browser initialization code
4. Attempt to modify bundled content and verify that signature verification fails
5. Test that signature verification failures prevent content loading
6. Verify that signature verification uses secure algorithms (RSA-2048+, ECDSA P-256+)
7. Test that signature verification cannot be bypassed or disabled
8. Verify that signing keys are properly protected in the host application
9. All local/bundled content has cryptographic signatures
10. Signature verification occurs before content execution
11. Modified content fails signature verification
12. Signature verification failures block content loading
13. Secure signature algorithms are used
14. Signature verification cannot be bypassed
15. Signing keys are protected from extraction
16. Verification process is logged

**Pass Criteria**: All local content is signed AND signatures are verified before execution AND verification cannot be bypassed

**Fail Criteria**: Unsigned content can be loaded OR signature verification is bypassable OR weak signature algorithms

**Evidence**: Signed content bundles, signature verification code review, test results with modified content, cryptographic algorithm analysis, key protection documentation

**References**:

- Code Signing Best Practices (NIST): https://csrc.nist.gov/publications/detail/sp/800-183/final
- Android APK Signature Scheme: https://source.android.com/docs/security/features/apksigning
- Authenticode for Windows: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode

### Assessment: EMB-REQ-24 (Redirect chain trust enforcement)

**Reference**: EMB-REQ-24 - Host applications shall implement mechanisms to detect and prevent redirect chains that exit trusted domains

**Given**: A conformant embedded browser with origin allowlist (EMB-1 or higher)

**Task**: Redirect chain trust enforcement prevents open redirect attacks where trusted origins inadvertently redirect to attacker-controlled domains, potentially exposing JavaScript bridge APIs to malicious content. Without redirect validation, attackers can exploit legitimate redirects on trusted sites to bypass origin allowlists, tricking the embedded browser into loading malicious content that appears to come from a trusted source. Multi-hop redirect chains are particularly dangerous because each hop in the chain could be manipulated to eventually land on an untrusted domain, requiring comprehensive validation of the entire redirect path to prevent trust boundary violations.

**Verification**:

1. Configure trusted origin allowlist in the embedded browser
2. Load a page from a trusted origin that redirects to another trusted origin
3. Verify that trusted-to-trusted redirects are allowed
4. Load a page from a trusted origin that redirects to an untrusted origin
5. Verify that trusted-to-untrusted redirects are blocked
6. Test multi-hop redirect chains: trusted → trusted → untrusted
7. Verify that all redirects in the chain are validated against allowlist
8. Test that redirect blocking triggers security logging
9. Verify that JavaScript-based redirects are also subject to trust enforcement
10. Redirect chain validation is enforced
11. Trusted-to-trusted redirects are allowed
12. Any redirect to untrusted origin is blocked
13. Multi-hop redirect chains are fully validated
14. Both HTTP and JavaScript redirects are subject to enforcement
15. Blocked redirects trigger error pages and security logs
16. Users are notified when redirects are blocked
17. No bypass mechanism exists for redirect enforcement

**Pass Criteria**: Redirect chains are fully validated AND untrusted redirects are blocked AND enforcement covers all redirect types

**Fail Criteria**: Redirects to untrusted origins succeed OR JavaScript redirects bypass enforcement OR multi-hop validation is incomplete

**Evidence**: Redirect test results, browser console showing blocked redirects, security logs, network traffic captures showing redirect chains, error page screenshots

**References**:

- OWASP Open Redirect: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html
- CWE-601: URL Redirection to Untrusted Site: https://cwe.mitre.org/data/definitions/601.html
- Android WebView shouldOverrideUrlLoading: https://developer.android.com/reference/android/webkit/WebViewClient#shouldOverrideUrlLoading(android.webkit.WebView,%20android.webkit.WebResourceRequest)
- iOS WKNavigationDelegate decidePolicyFor: https://developer.apple.com/documentation/webkit/wknavigationdelegate/1455641-webview

### Assessment: EMB-REQ-25 (HSTS enforcement for trusted origins)

**Reference**: EMB-REQ-25 - Embedded browsers shall enforce strict transport security (HSTS) for all trusted content origins

**Given**: A conformant embedded browser (EMB-1 or higher)

**Task**: HSTS enforcement for trusted origins protects against SSL stripping attacks where network attackers intercept initial HTTP requests and prevent upgrade to HTTPS, allowing interception of all subsequent traffic. Without HSTS, embedded browsers are vulnerable during the brief window between application launch and the first HTTPS connection, when attackers can downgrade connections to HTTP and conduct man-in-the-middle attacks. HSTS ensures that all connections to trusted origins use HTTPS, with non-bypassable certificate validation, preventing network-level attackers from intercepting or modifying content loaded by the embedded browser even on compromised networks.

**Verification**:

1. Configure trusted content origins with HSTS headers: `Strict-Transport-Security: max-age=31536000; includeSubDomains; preload`
2. Make initial HTTPS request to trusted origin and verify HSTS header is received and cached
3. Attempt to make HTTP request to same origin and verify automatic upgrade to HTTPS
4. Test that HSTS enforcement continues after browser restart (persistence)
5. Verify that HSTS includeSubDomains flag is respected for subdomains
6. Test that HSTS preload list is supported and enforced
7. Attempt to bypass HSTS through direct IP access or hosts file manipulation
8. Verify that certificate errors on HSTS hosts cannot be bypassed
9. HSTS headers are parsed and cached correctly
10. HTTP requests to HSTS hosts are automatically upgraded to HTTPS
11. HSTS state persists across browser sessions
12. includeSubDomains flag applies to all subdomains
13. HSTS preload list is maintained and enforced
14. HSTS cannot be bypassed through IP access or other means
15. Certificate errors on HSTS hosts are non-bypassable
16. HSTS enforcement is logged

**Pass Criteria**: HSTS is enforced for all trusted origins AND HTTP is automatically upgraded AND certificate errors are non-bypassable

**Fail Criteria**: HSTS can be bypassed OR HTTP connections succeed to HSTS hosts OR certificate errors are bypassable

**Evidence**: Network traffic captures showing HTTPS upgrades, HSTS cache inspection, test results with HTTP requests, certificate error bypass attempts, HSTS preload list verification

**References**:

- RFC 6797: HTTP Strict Transport Security (HSTS): https://datatracker.ietf.org/doc/html/rfc6797
- HSTS Preload List: https://hstspreload.org/
- OWASP HSTS: https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html
- Chromium HSTS Implementation: https://www.chromium.org/hsts

### Assessment: EMB-REQ-26 (Certificate validation failure notification)

**Reference**: EMB-REQ-26 - Certificate validation failures for trusted content sources shall trigger immediate user notification and content blocking

**Given**: A conformant embedded browser loading trusted remote content (EMB-1 or higher)

**Task**: Immediate notification and blocking on certificate validation failures for trusted content prevents silent man-in-the-middle attacks where users unknowingly interact with compromised content. Without clear error notifications and strict blocking, users might not realize that certificate validation has failed, allowing attackers to serve malicious content that appears to come from trusted origins. Non-bypassable certificate error handling for trusted origins ensures that even sophisticated attacks using fraudulent certificates cannot trick the embedded browser into loading untrusted content, protecting the integrity of the JavaScript bridge API access model.

**Verification**:

1. Configure trusted content origins with valid certificates
2. Simulate certificate validation failures: expired certificate, hostname mismatch, untrusted CA, revoked certificate
3. Verify that each failure type triggers immediate error notification
4. Verify that content loading is completely blocked (no partial loading)
5. Test that error notifications clearly explain the problem to users
6. Verify that no "continue anyway" option exists for trusted origin failures
7. Test that certificate failures are logged to security event log
8. Verify that host application is notified of certificate failures via callback
9. Certificate validation failures are detected for all failure types
10. User receives immediate, clear error notification
11. Content loading is completely blocked on validation failure
12. Error messages explain the specific certificate problem
13. No bypass mechanism exists for certificate errors on trusted origins
14. Certificate failures are logged with full details
15. Host application can register for certificate failure callbacks
16. Failure handling differs for trusted vs. untrusted origins

**Pass Criteria**: All certificate failures block content AND trigger immediate user notification AND are non-bypassable for trusted origins

**Fail Criteria**: Any certificate failure allows content loading OR notifications are missing/unclear OR bypass options exist

**Evidence**: Error page screenshots, certificate failure logs, test results with various failure types, user notification interface documentation, host callback implementation

**References**:

- RFC 5280: Certificate Validation: https://datatracker.ietf.org/doc/html/rfc5280
- CA/Browser Forum Baseline Requirements: https://cabforum.org/baseline-requirements-documents/
- Android WebView onReceivedSslError: https://developer.android.com/reference/android/webkit/WebViewClient#onReceivedSslError(android.webkit.WebView,%20android.webkit.SslErrorHandler,%20android.net.http.SslError)
- iOS WKNavigationDelegate didReceive challenge: https://developer.apple.com/documentation/webkit/wknavigationdelegate/1455638-webview

### Assessment: EMB-REQ-27 (Network security configuration)

**Reference**: EMB-REQ-27 - Host applications shall implement network security configurations that prevent cleartext traffic to trusted domains

**Given**: A conformant embedded browser (EMB-1 or higher)

**Task**:

1. Review network security configuration for the embedded browser (Android Network Security Config, iOS App Transport Security, or equivalent)
2. Verify that cleartext HTTP traffic is disabled for trusted domains
3. Attempt to make HTTP requests to trusted domains and verify they are blocked
4. Test that HTTPS-only enforcement cannot be disabled at runtime
5. Verify that network security configuration applies to all network APIs (WebView, XHR, fetch, WebSocket)
6. Test that certificate pinning configuration is integrated with network security config
7. Verify that configuration is declarative and cannot be modified by web content
8. Test that cleartext traffic blocking is logged

**Verification**:

- Network security configuration enforces HTTPS-only for trusted domains
- Cleartext HTTP traffic is blocked at the network layer
- HTTPS enforcement applies to all network APIs uniformly
- Configuration is declarative and immutable at runtime
- Certificate pinning is integrated into network security config
- Blocked cleartext traffic is logged
- Configuration is documented and auditable
- Platform-specific security features are properly utilized (NSConfig, ATS)

**Pass Criteria**: Cleartext traffic to trusted domains is blocked at network layer AND configuration is immutable AND applies to all network APIs

**Fail Criteria**: Cleartext traffic succeeds to trusted domains OR configuration can be modified OR inconsistent enforcement across APIs

**Evidence**: Network security configuration files, network traffic captures showing blocked HTTP, test results with various network APIs, configuration documentation, platform security feature usage audit

**References**:

- Android Network Security Configuration: https://developer.android.com/training/articles/security-config
- iOS App Transport Security: https://developer.apple.com/documentation/security/preventing_insecure_network_connections
- CWE-319: Cleartext Transmission of Sensitive Information: https://cwe.mitre.org/data/definitions/319.html

### Assessment: EMB-REQ-28 (CSP enforcement for third-party content)

**Reference**: EMB-REQ-28 - Embedded browsers shall prevent trusted content from loading untrusted third-party content without explicit CSP declarations

**Given**: A conformant embedded browser with CSP support (EMB-1 or higher)

**Task**:

1. Configure trusted content page with restrictive CSP that allows only specific third-party domains
2. Attempt to load third-party content from CSP-allowed domains and verify success
3. Attempt to load third-party content from non-allowed domains and verify blocking
4. Test that inline scripts from third-party content are blocked unless allowed by CSP
5. Verify that CSP applies to all third-party resource types (scripts, styles, images, frames)
6. Test that CSP violations are reported via report-uri or report-to
7. Verify that web content cannot weaken or disable CSP policy
8. Test that host-configured CSP takes precedence over page-specified CSP

**Verification**:

- CSP restricts third-party content loading to explicitly allowed domains
- Non-allowed third-party content is blocked
- CSP applies consistently across all resource types
- CSP violations generate reports to configured endpoint
- Web content cannot bypass or weaken CSP restrictions
- Host-configured CSP cannot be overridden by page CSP
- CSP enforcement is logged
- Default CSP policy is restrictive (deny by default)

**Pass Criteria**: Third-party content loading is restricted by CSP AND violations are blocked and reported AND policy cannot be weakened by web content

**Fail Criteria**: Third-party content bypasses CSP OR policy can be weakened OR violations not reported

**Evidence**: CSP policy headers, browser console showing CSP violations, violation reports, test results with blocked third-party content, network traffic analysis

**References**:

- Content Security Policy Level 3: https://www.w3.org/TR/CSP3/
- CSP script-src directive: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src
- CSP Reporting: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#reporting
- OWASP CSP Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html

### Assessment: EMB-REQ-29 (Per-instance trust policies)

**Reference**: EMB-REQ-29 - Trust policies shall be configurable per embedded browser instance to support multi-tenant applications

**Given**: A conformant embedded browser supporting multiple instances (EMB-2 or higher)

**Task**:

1. Create multiple embedded browser instances within the same host application
2. Configure different trust policies for each instance: different origin allowlists, different certificate pins, different CSP policies
3. Load content in each instance and verify that instance-specific policies are enforced
4. Verify that instances cannot access each other's storage or state
5. Test that trust policy configuration is isolated per instance
6. Attempt to modify one instance's trust policy from another instance
7. Verify that instance destruction cleans up trust policy state
8. Test that host application can dynamically create instances with custom policies

**Verification**:

- Trust policies can be configured independently per instance
- Each instance enforces its own trust policy correctly
- Instances are isolated from each other (no cross-instance access)
- Trust policy configuration is scoped to individual instances
- Instance creation accepts custom policy configuration
- Instance destruction cleans up policy state
- No interference between instances' trust enforcement
- Multi-tenant scenarios are properly supported

**Pass Criteria**: Per-instance trust policies are supported AND enforced correctly AND instances are isolated from each other

**Fail Criteria**: Policies cannot be configured per-instance OR instances interfere with each other OR policy isolation is broken

**Evidence**: Code showing per-instance policy configuration, test results with multiple instances, storage isolation verification, policy enforcement logs per instance, multi-tenant test scenarios

**References**:

- Android WebView Multiple Instances: https://developer.android.com/reference/android/webkit/WebView
- iOS WKWebView Configuration: https://developer.apple.com/documentation/webkit/wkwebviewconfiguration
- Electron BrowserView Isolation: https://www.electronjs.org/docs/latest/api/browser-view
- Multi-tenancy Security Best Practices: https://owasp.org/www-project-application-security-verification-standard/

### Assessment: EMB-REQ-30 (Certificate Transparency verification)

**Reference**: EMB-REQ-30 - Embedded browsers shall implement certificate transparency verification for trusted content origins

**Given**: A conformant embedded browser with Certificate Transparency support (EMB-2 or higher)

**Task**:

1. Configure trusted content origins that require Certificate Transparency
2. Load content from origins with valid SCTs (Signed Certificate Timestamps) in certificates or via TLS extension
3. Verify that content loads successfully when valid SCTs are present
4. Attempt to load content with certificates lacking SCTs from CT-required origins
5. Verify that missing or invalid SCTs block content loading for CT-required origins
6. Test that SCTs are validated against known CT logs
7. Verify that CT enforcement can be configured per-origin or globally
8. Test that CT validation failures are logged

**Verification**:

- Certificate Transparency verification is supported
- Valid SCTs allow content loading from CT-required origins
- Missing or invalid SCTs block content loading
- SCTs are validated against known CT logs
- CT enforcement policy is configurable (per-origin or global)
- CT validation failures generate clear error messages and logs
- CT log list is kept up-to-date
- CT enforcement integrates with certificate validation flow

**Pass Criteria**: CT verification is implemented AND enforced for configured origins AND invalid SCTs block content loading

**Fail Criteria**: CT verification not implemented OR can be bypassed OR invalid SCTs are accepted

**Evidence**: Network traffic captures showing SCTs, CT validation logs, test results with missing SCTs, CT log list version verification, CT enforcement configuration

**References**:

- RFC 6962: Certificate Transparency: https://datatracker.ietf.org/doc/html/rfc6962
- Chromium CT Policy: https://www.chromium.org/Home/chromium-security/certificate-transparency/
- Certificate Transparency Logs: https://www.certificate-transparency.org/
- Google CT Policy: https://github.com/GoogleChrome/CertificateTransparency/blob/master/ct_policy.md

### Assessment: EMB-REQ-31 (DNS rebinding attack prevention)

**Reference**: EMB-REQ-31 - Host applications shall detect and prevent DNS rebinding attacks targeting trusted local/internal origins

**Given**: A conformant embedded browser with local/internal origin access (EMB-2 or higher)

**Task**:

1. Identify local/internal origins accessed by the embedded browser (localhost, 127.0.0.1, private IP ranges, .local domains)
2. Simulate DNS rebinding attack: external domain initially resolves to attacker IP, then rebinds to local/internal IP
3. Verify that DNS rebinding is detected and blocked
4. Test DNS cache behavior and TTL enforcement
5. Verify that private IP address access requires explicit allowlisting
6. Test that DNS resolution results are validated against expected address ranges
7. Verify that Host header validation prevents rebinding exploitation
8. Test that DNS rebinding attempts trigger security logging

**Verification**:

- DNS rebinding attacks are detected
- Unexpected DNS resolution changes trigger blocking
- Private IP address access requires explicit configuration
- DNS cache prevents rapid rebinding
- Host header validation is enforced
- Resolution results are validated against address allowlists
- Rebinding attempts are logged as security events
- Local/internal origins have additional protection

**Pass Criteria**: DNS rebinding attacks are detected and blocked AND private IP access is restricted AND rebinding attempts are logged

**Fail Criteria**: DNS rebinding succeeds OR no private IP restrictions OR rebinding not detected

**Evidence**: DNS rebinding test results, DNS cache configuration, Host header validation tests, security logs showing rebinding attempts, private IP access policy documentation

**References**:

- DNS Rebinding Explained: https://en.wikipedia.org/wiki/DNS_rebinding
- CWE-346: Origin Validation Error: https://cwe.mitre.org/data/definitions/346.html
- Private Network Access specification: https://wicg.github.io/private-network-access/

### Assessment: EMB-REQ-32 (Trust boundary violation security events)

**Reference**: EMB-REQ-32 - Trust boundary violations shall trigger security events with sufficient context for incident response

**Given**: A conformant embedded browser with comprehensive logging (EMB-1 or higher)

**Task**:

1. Configure security event logging for the embedded browser
2. Trigger various trust boundary violations: accessing blocked origins, calling restricted APIs, certificate validation failures, CSP violations
3. Review generated security events and verify they contain: timestamp, event type, origin/source, detailed description, severity level, stack trace/context
4. Verify that security events are distinct from general application logs
5. Test that security events can be forwarded to SIEM or security monitoring systems
6. Verify that high-severity violations trigger immediate alerts
7. Test that security events include sufficient context for incident investigation
8. Verify that event generation does not disrupt application functionality

**Verification**:

- Trust boundary violations generate security events
- Events include comprehensive context: timestamp, type, origin, description, severity
- Events are distinguishable from general logs (separate channel or marked)
- Events can be exported or forwarded to security monitoring systems
- High-severity events trigger immediate alerts
- Events include actionable information for incident response
- Event logging is reliable and does not impact app stability
- Events are tamper-resistant

**Pass Criteria**: All boundary violations generate security events AND events include sufficient context AND can be forwarded to monitoring systems

**Fail Criteria**: Violations don't generate events OR insufficient context OR cannot be monitored externally

**Evidence**: Security event log samples, event schema documentation, SIEM integration configuration, alert configuration, incident response playbooks referencing events, event log integrity verification

**References**:

- NIST SP 800-61: Computer Security Incident Handling Guide: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final
- OWASP Logging Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
- CEF (Common Event Format): https://www.microfocus.com/documentation/arcsight/arcsight-smartconnectors/pdfdoc/common-event-format-v25/common-event-format-v25.pdf
- SIEM Integration Best Practices: https://www.sans.org/white-papers/36427/

# Annex A (informative): Mapping between the present document and CRA requirements

_Table mapping technical security requirements from Section 5 of the present document to essential cybersecurity requirements in Annex I of the CRA. The purpose of this is to help identify missing technical security requirements._

| CRA requirement                                 | Technical security requirements(s) |
|-------------------------------------------------|------------------------------------|
| No known exploitable vulnerabilities            | UPD-0-REQ-1 through UPD-0-REQ-24 (Forced automatic updates), UPD-1-REQ-1 through UPD-1-REQ-25 (Automatic updates with postponement), LOG-REQ-14 (Incident detection), LOG-REQ-15 (Audit trail completeness), EMB-REQ-9 (JavaScript bridge security review), EXT-REQ-4 (Manifest validation), EXT-REQ-17 (Extension signature validation) |
| Secure design, development, production          | EMB-REQ-9 (JavaScript bridge security review), EXT-REQ-4 (Manifest validation), EXT-REQ-17 (Extension signature validation), UPD-REQ-2 (Update signature verification), UPD-REQ-23 (Binary reproducibility), ENC-REQ-12 (Secure random number generation), SYS-REQ-26 (Sandbox escape prevention), SYS-REQ-27 (Spectre/Meltdown mitigations), SYS-REQ-28 (Side-channel mitigations) |
| Secure by default configuration                 | DOM-0-REQ-1 through DOM-0-REQ-6 (Full isolation by default), ENC-0-REQ-1 through ENC-0-REQ-23 (Full encryption by default), DOM-REQ-5 (SameSite=Lax default), DOM-REQ-12 (document.domain restricted by default), ENC-REQ-16 (HTTPS-first mode), UPD-0-REQ-1 (Automatic updates enabled by default), LOG-REQ-9 (User consent for telemetry), SYS-0-REQ-1 through SYS-0-REQ-13 (Sandboxed by default), EMB-0-REQ-1 through EMB-0-REQ-7 (Isolated by default) |
| Secure updates                                  | UPD-REQ-1 (Automatic update mechanism), UPD-REQ-2 (Update signature verification), UPD-REQ-3 (HTTPS-only delivery), UPD-REQ-4 (Manifest integrity), UPD-REQ-5 (Rollback protection), UPD-REQ-6 (Channel isolation), UPD-REQ-7 (Component updates), UPD-REQ-8 (Emergency updates), UPD-REQ-9 (Verification before installation), UPD-REQ-10 (Failure recovery), UPD-REQ-11 (Transparency logging), UPD-REQ-12 (Delta update security), UPD-REQ-13 (Server authentication), UPD-REQ-14 (Timing jitter), UPD-REQ-15 (Background enforcement), UPD-REQ-16 (Notification UI), UPD-REQ-17 (Forced critical updates), UPD-REQ-18 (Verification chain), UPD-REQ-19 (Source pinning), UPD-REQ-20 (Integrity verification), UPD-REQ-21 (Staged rollout), UPD-REQ-22 (Domain validation), UPD-REQ-23 (Binary reproducibility), EXT-REQ-10 (Extension update verification) |
| Authentication and access control mechanisms    | DOM-REQ-1 (Process-per-site isolation), DOM-REQ-3 (Cross-origin DOM access prevention), DOM-REQ-4 (CORS preflight), DOM-REQ-5 (SameSite cookies), DOM-REQ-6 (Storage isolation), EXT-REQ-1 (Extension permission model), EXT-REQ-3 (Extension API access control), EXT-REQ-7 (Host permissions validation), SYS-REQ-6 (Device API permissions), SYS-REQ-7 (PWA permission management), SYS-REQ-8 through SYS-REQ-19 (Device-specific permissions), EMB-REQ-1 (JavaScript bridge API allowlists), EMB-REQ-5 (User consent for sensitive operations), EMB-REQ-11 (Granular capability-based permissions), PRO-REQ-2 (User consent for custom protocols), PRO-REQ-3 (Protocol allowlist enforcement) |
| Confidentiality protection                      | ENC-REQ-1 (TLS 1.3+ support), ENC-REQ-2 (Certificate validation), ENC-REQ-3 (Certificate pinning), ENC-REQ-4 (HSTS enforcement), ENC-REQ-5 (Mixed content blocking), ENC-REQ-6 (Certificate Transparency), ENC-REQ-11 (Web Crypto API), ENC-REQ-13 (Subresource Integrity), ENC-REQ-14 (Encrypted SNI/ECH), ENC-REQ-16 (HTTPS-first mode), ENC-REQ-20 (Cryptographic key isolation), ENC-REQ-21 (Certificate store security), DOM-REQ-2 (CORB), DOM-REQ-6 (Storage isolation), EMB-REQ-4 (Context isolation), EMB-REQ-8 (Host credential protection), EMB-REQ-12 (Storage isolation from host), EMB-REQ-14 (Encrypted cross-process bridge), EMB-REQ-17 (Certificate validation for embedded content), EMB-REQ-21 (Mixed content prevention), EMB-REQ-27 (Network security configuration) |
| Integrity protection for data and configuration | ENC-REQ-2 (Certificate validation), ENC-REQ-13 (Subresource Integrity), UPD-REQ-2 (Update signature verification), UPD-REQ-4 (Update manifest integrity), UPD-REQ-5 (Rollback protection), UPD-REQ-20 (Update integrity verification), LOG-REQ-11 (Log integrity protection), EMB-REQ-2 (JavaScript bridge input validation), EMB-REQ-7 (Immutable bridge configuration), EMB-REQ-19 (SRI for embedded content), EMB-REQ-23 (Cryptographic signature verification for local content), EXT-REQ-4 (Manifest validation), EXT-REQ-17 (Extension signature validation), DOM-REQ-9 (CORP), DOM-REQ-11 (COEP) |
| Data minimization                               | LOG-REQ-7 (Log data minimization), LOG-REQ-8 (Log anonymization), LOG-REQ-12 (Log retention policies), LOG-REQ-18 (Privacy-preserving analytics), EXT-REQ-16 (Extension telemetry privacy), DOM-REQ-6 (Storage isolation limits data sharing), EMB-REQ-12 (Storage isolation from host), PRO-REQ-5 (Protocol parameter sanitization to prevent data leakage) |
| Availability protection                         | SYS-REQ-20 (Hardware resource limits), SYS-REQ-21 (Memory isolation), SYS-REQ-22 (CPU quotas), SYS-REQ-23 (Network bandwidth limits), SYS-REQ-24 (Storage quotas), SYS-REQ-25 (Process priority management), UPD-REQ-10 (Update failure recovery), UPD-REQ-21 (Staged rollout), EMB-REQ-10 (Bridge API rate limiting), EXT-REQ-5 (Extension sandboxing to prevent interference) |
| Minimize impact on other devices or services    | DOM-REQ-1 (Process-per-site isolation), SYS-REQ-1 (Process sandbox enforcement), SYS-REQ-2 (Renderer process isolation), SYS-REQ-3 (GPU process isolation), SYS-REQ-4 (Network service isolation), SYS-REQ-20 (Resource limits), SYS-REQ-26 (Sandbox escape prevention), EXT-REQ-5 (Extension sandboxing), EXT-REQ-6 (Cross-extension isolation), EMB-REQ-4 (Context isolation), PRO-REQ-13 (Handler capability restrictions) |
| Limit attack surface                            | EXT-0-REQ-1 through EXT-0-REQ-3 (No extension support), SYS-0-REQ-1 through SYS-0-REQ-13 (Fully sandboxed), EMB-0-REQ-1 through EMB-0-REQ-7 (No JavaScript bridge), PRO-0-REQ-1 through PRO-0-REQ-5 (HTTP/HTTPS only), DOM-REQ-7 (iframe sandboxing), DOM-REQ-8 (Opaque origin handling), EMB-REQ-6 (No system-level API exposure), EMB-REQ-16 (Allowlists over denylists), EXT-REQ-12 (Background script restrictions), ENC-REQ-19 (Legacy crypto deprecation) |
| Exploit mitigation by limiting incident impact  | DOM-REQ-1 (Process-per-site isolation limits cross-site impact), SYS-REQ-1 (Sandbox enforcement), SYS-REQ-2 (Process isolation), SYS-REQ-21 (Memory isolation), SYS-REQ-26 (Sandbox escape prevention), SYS-REQ-27 (Spectre/Meltdown mitigations), SYS-REQ-28 (Side-channel mitigations), DOM-REQ-2 (CORB), DOM-REQ-9 (CORP), DOM-REQ-10 (COOP), DOM-REQ-11 (COEP), EXT-REQ-2 (Content script isolation), EXT-REQ-5 (Extension sandboxing), EXT-REQ-6 (Cross-extension isolation), EMB-REQ-4 (Context isolation), UPD-REQ-5 (Rollback protection), UPD-REQ-21 (Staged rollout limits blast radius) |
| Logging and monitoring mechanisms               | LOG-REQ-1 (Security event logging), LOG-REQ-2 (Certificate error logging), LOG-REQ-3 (Extension security events), LOG-REQ-4 (CSP violation reporting), LOG-REQ-5 (Network Error Logging), LOG-REQ-6 (Crash reporting), LOG-REQ-10 (Secure log transmission), LOG-REQ-11 (Log integrity protection), LOG-REQ-13 (Security dashboard), LOG-REQ-14 (Incident detection), LOG-REQ-15 (Audit trail completeness), LOG-REQ-16 (Real-time security alerts), LOG-REQ-17 (Forensic log export), LOG-REQ-19 (Compliance logging), LOG-REQ-20 (Log access controls), EMB-REQ-3 (JavaScript bridge logging), EMB-REQ-22 (Trust decision logging), EMB-REQ-32 (Trust boundary violation events), UPD-REQ-11 (Update transparency logging), PRO-REQ-9 (Protocol handler logging) |
| Secure deletion and data transfer               | DOM-REQ-6 (Storage isolation enables secure per-origin deletion), ENC-REQ-1 (TLS 1.3+ for secure transfer), ENC-REQ-3 (Certificate pinning for critical transfers), ENC-REQ-5 (Mixed content blocking), EMB-REQ-17 (Certificate validation for embedded content transfers), EMB-REQ-21 (Mixed content prevention), EMB-REQ-27 (Network security configuration), SYS-REQ-24 (Storage quotas with cleanup mechanisms), EXT-REQ-11 (Extension storage isolation enables clean uninstall) |

# Annex B (informative): Mapping of Use Cases to Capabilities and Requirements

This annex provides a comprehensive mapping of each use case defined in Section 4.4 to the relevant browser capabilities and their associated requirement sets. This mapping helps manufacturers and assessors identify which requirements apply to specific deployment contexts.

## B.1 Use Case Mapping Methodology

For each use case, the mapping identifies:

1. **Primary Capabilities**: Core security capabilities that are essential for the use case
2. **Recommended Condition Levels**: Specific condition levels (e.g., DOM-1, EXT-2) appropriate for the use case's risk profile
3. **Critical Requirements**: Specific requirement sets that are satisfied for the use case
4. **Optional Enhancements**: Additional requirements that may be appropriate based on deployment specifics

## B.2 Use Case to Capability Mappings

### UC-B1: General Purpose Web Browsing (Risk Level: Standard)

**Primary Capabilities and Recommended Conditions**:

- **DOM (Domain/Origin Isolation)**: DOM-1 (Controlled isolation)
- **EXT (Extension System)**: EXT-1 or EXT-2
- **ENC (Encryption)**: ENC-1
- **LOG (Logging/Monitoring)**: LOG-1
- **UPD (Updates)**: UPD-1
- **PRO (Protocol Handlers)**: PRO-1
- **SYS (System Resources)**: SYS-1

**Critical Requirements**: DOM-1-REQ-1 through DOM-1-REQ-9, ENC-1-REQ-1 through ENC-1-REQ-19, UPD-1-REQ-1 through UPD-1-REQ-25, EXT-1-REQ-1 through EXT-1-REQ-14, LOG-1-REQ-1 through LOG-1-REQ-18, SYS-1-REQ-1 through SYS-1-REQ-22

**Assessment References**: All DOM, ENC, UPD, EXT, LOG, PRO, SYS assessments apply

---

### UC-B2: Development and Testing Environments (Risk Level: High)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-2
- **EXT**: EXT-2
- **ENC**: ENC-1
- **LOG**: LOG-2
- **UPD**: UPD-1 or UPD-2
- **PRO**: PRO-2
- **SYS**: SYS-2

**Critical Requirements**: DOM-2-REQ-1 through DOM-2-REQ-12, EXT-2-REQ-1 through EXT-2-REQ-10, LOG-2-REQ-1 through LOG-2-REQ-20, PRO-2-REQ-1 through PRO-2-REQ-12, SYS-2-REQ-1 through SYS-2-REQ-15

**Assessment References**: All capability assessments, emphasis on EXT-REQ-9, DOM-REQ-9-11, SYS-REQ-14-17

---

### UC-B3: Kiosks and Shared Terminals (Risk Level: High)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-0 or DOM-1
- **EXT**: EXT-0
- **ENC**: ENC-0 or ENC-1
- **LOG**: LOG-3
- **UPD**: UPD-0
- **PRO**: PRO-0
- **SYS**: SYS-0
- **EMB** (if embedded): EMB-1 or EMB-2

**Critical Requirements**: DOM-0-REQ-1 through DOM-0-REQ-6, EXT-0-REQ-1 through EXT-0-REQ-3, ENC-0-REQ-1 through ENC-0-REQ-23, LOG-3-REQ-1 through LOG-3-REQ-20, UPD-0-REQ-1 through UPD-0-REQ-24, PRO-0-REQ-1 through PRO-0-REQ-5, SYS-0-REQ-1 through SYS-0-REQ-13

**If Embedded**: EMB-1-REQ-1 through EMB-1-REQ-17, EMB-REQ-8, EMB-REQ-3, EMB-REQ-22

**Additional**: Domain allowlisting, session auto-termination, no credential storage, remote monitoring

**Assessment References**: Strictest criteria; DOM-REQ-1-8, ENC-REQ-1-6, UPD-REQ-1-11, SYS-REQ-1-4, LOG-REQ-10-11

---

### UC-B4: Financial Services Access (Risk Level: High)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-1
- **EXT**: EXT-1
- **ENC**: ENC-0 or ENC-1
- **LOG**: LOG-1
- **UPD**: UPD-0 or UPD-1
- **PRO**: PRO-1
- **SYS**: SYS-1
- **EMB** (if embedded): EMB-1 or EMB-2

**Critical Requirements**: ENC-0-REQ-1 through ENC-0-REQ-23 OR ENC-1-REQ-1 through ENC-1-REQ-19, DOM-1-REQ-1 through DOM-1-REQ-9, EXT-1-REQ-1 through EXT-1-REQ-14, LOG-REQ-2, LOG-REQ-14

**If Embedded**: EMB-1-REQ-1 through EMB-1-REQ-17, EMB-REQ-17, EMB-REQ-20, EMB-REQ-2, EMB-REQ-8

**Assessment References**: ENC-REQ-1-7, ENC-REQ-17, DOM-REQ-5, LOG-REQ-2, EMB-REQ-1-10 (if embedded)

---

### UC-B5: Healthcare and Medical Systems (Risk Level: High)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-1 or DOM-2
- **EXT**: EXT-1
- **ENC**: ENC-0
- **LOG**: LOG-3
- **UPD**: UPD-0 or UPD-1
- **PRO**: PRO-1
- **SYS**: SYS-1
- **EMB** (if embedded): EMB-1 or EMB-2

**Critical Requirements**: ENC-0-REQ-1 through ENC-0-REQ-23, LOG-3-REQ-1 through LOG-3-REQ-20, LOG-REQ-7, LOG-REQ-8, LOG-REQ-19, DOM-1-REQ-1 through DOM-1-REQ-9, UPD-0-REQ-17, EXT-1-REQ-1 through EXT-1-REQ-14