EN-304-617_v0.0.6.md

**Task**: User consent for sensitive APIs is critical to prevent malicious web content from silently accessing privacy-sensitive functionality like camera, microphone, location, files, or contacts without the user's knowledge. Without explicit consent requirements, attackers can exploit JavaScript bridge APIs to exfiltrate sensitive data, track user location, or access private information. Proper consent mechanisms protect users from invisible attacks where compromised or malicious web content attempts unauthorized access to device capabilities that could violate user privacy or security expectations.

**Verification**:

1. Identify all sensitive operations exposed via the JavaScript bridge (e.g., file access, location, camera, contacts, payments) → Confirm that consent state persists across browser sessions according to user choice
2. Attempt to invoke sensitive APIs from web content without prior user consent → Sensitive API calls trigger user consent prompts before execution
3. Verify that a clear, non-dismissible consent dialog appears for each sensitive operation → Consent dialogs clearly identify the origin and permission type
4. Test that consent dialogs clearly identify the requesting origin and the specific permission being requested → Users can grant, deny, or revoke permissions
5. Verify that consent can be granted permanently, temporarily (session-only), or denied → Denied permissions prevent API execution
6. Test that denied permissions are enforced consistently → Consent state is properly persisted and enforced
7. Verify that users can revoke previously granted permissions → No sensitive operations occur without explicit user consent

**Pass Criteria**: All sensitive API calls require explicit user consent AND consent UI is clear and non-spoofable AND permission state is properly enforced

**Fail Criteria**: Any sensitive operation occurs without user consent OR consent UI is bypassable OR permissions are not enforced

**Evidence**: Screenshots of consent dialogs, test results showing blocked operations without consent, user consent audit logs, permission state persistence verification

**References**:

- Android Runtime Permissions: https://developer.android.com/training/permissions/requesting
- iOS Permission Prompts: https://developer.apple.com/design/human-interface-guidelines/patterns/accessing-private-data
- W3C Permissions API: https://www.w3.org/TR/permissions/

### Assessment: EMB-REQ-6 (No system-level API exposure without controls)

**Reference**: EMB-REQ-6 - Host applications shall not expose system-level APIs (file system, process execution, native module loading) through JavaScript bridges without additional security controls

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

**Task**: Exposing system-level APIs through JavaScript bridges without strict controls creates critical vulnerabilities that can lead to arbitrary code execution, data exfiltration, or complete system compromise. Malicious web content could exploit unrestricted file system access to read sensitive files, execute arbitrary commands to take control of the host system, or load native modules to escalate privileges. Path traversal attacks could bypass directory restrictions, and unbounded network socket access could enable attackers to pivot to internal systems, making proper security controls on system-level APIs absolutely essential for embedded browser security.

**Verification**:

1. Review all APIs exposed via the JavaScript bridge → System-level APIs either not exposed or have strict security controls
2. Identify any system-level capabilities: file system access, process/command execution, native module loading, network socket access, registry access → File system access is restricted to specific allowlisted directories
3. For each system-level API, verify additional security controls exist: capability-based permissions, path allowlisting, command allowlisting, sandboxing, user consent → Command execution is restricted to specific allowlisted commands or completely prohibited
4. Attempt to use exposed file system APIs to access sensitive paths (/etc/passwd, C:\\Windows\\System32, application data directories) → Native module loading is restricted or prohibited
5. Attempt to execute arbitrary commands or load arbitrary native modules → Path traversal attacks are prevented
6. Test that path traversal sequences (../, ..\\) are blocked or neutralized → System-level operations require elevated permissions or user consent
7. Verify that system-level operations are logged extensively → All system-level operations are logged with full details
8. Confirm that least-privilege principles are enforced (minimal necessary access) → Security controls cannot be bypassed

**Pass Criteria**: No unrestricted system-level APIs are exposed AND all system APIs have additional security controls AND controls are enforced effectively

**Fail Criteria**: Any system-level API is exposed without restrictions OR security controls can be bypassed OR arbitrary file/command access is possible

**Evidence**: API documentation, code review of exposed APIs, penetration test results, logs showing blocked system access attempts, security architecture documentation

**References**:

- CWE-78: OS Command Injection: https://cwe.mitre.org/data/definitions/78.html
- CWE-22: Path Traversal: https://cwe.mitre.org/data/definitions/22.html
- OWASP Command Injection: https://owasp.org/www-community/attacks/Command_Injection
- Electron Security Best Practices - Shell Execution: https://www.electronjs.org/docs/latest/tutorial/security#6-do-not-use-shellexecuteshellopen-or-related-methods-with-user-content
- Android File System Security: https://developer.android.com/training/data-storage

### Assessment: EMB-REQ-7 (Immutable bridge configuration)

**Reference**: EMB-REQ-7 - JavaScript bridge configurations shall be immutable after WebView initialization to prevent runtime tampering

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

**Task**: Immutable bridge configuration prevents runtime tampering attacks where malicious code attempts to dynamically modify the JavaScript bridge to add new attack surfaces, remove security controls, or replace legitimate APIs with malicious implementations. If configuration can be changed after initialization, attackers could exploit race conditions, code injection vulnerabilities, or confused deputy scenarios to inject malicious APIs, escalate privileges, or disable security restrictions. Configuration immutability ensures that the security boundary established at initialization time cannot be undermined during runtime.

**Verification**:

1. Initialize the embedded browser with a specific JavaScript bridge configuration → Verify that attempting to modify configuration triggers security logging
2. After initialization, attempt to modify the bridge configuration from host application code → Bridge configuration is set during initialization and cannot be changed afterward
3. From web content, attempt to add new APIs to the bridge dynamically → Host application cannot add or remove bridge APIs after initialization
4. Test if existing bridge APIs can be removed or replaced at runtime → Web content cannot influence bridge configuration
5. Verify that configuration changes after initialization either fail or require browser restart → Attempts to modify configuration fail with appropriate errors
6. Test that web content cannot influence bridge configuration through any means → Configuration immutability is enforced at the code level
7. Review code to confirm configuration is set during initialization phase only → Any attempted configuration changes are logged as security events

**Pass Criteria**: Bridge configuration is immutable after initialization AND modification attempts fail AND attempts are logged

**Fail Criteria**: Configuration can be modified after initialization OR web content can influence configuration

**Evidence**: Code review showing configuration immutability enforcement, test results showing failed modification attempts, security logs showing configuration change attempts, API documentation

**References**:

- Android WebView Configuration Best Practices: https://developer.android.com/reference/android/webkit/WebSettings
- iOS WKWebView Configuration Immutability: https://developer.apple.com/documentation/webkit/wkwebviewconfiguration
- Electron Security - Immutable Configuration: https://www.electronjs.org/docs/latest/tutorial/security
- CWE-732: Incorrect Permission Assignment: https://cwe.mitre.org/data/definitions/732.html

### Assessment: EMB-REQ-8 (Host credential protection)

**Reference**: EMB-REQ-8 - Embedded browsers shall prevent web content from accessing host application credentials, tokens, or cryptographic keys

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

**Task**: Protecting host credentials from web content access is essential to prevent credential theft attacks where malicious web content attempts to steal authentication tokens, API keys, or cryptographic keys stored by the host application. If web content can access host credentials through JavaScript bridge APIs, shared storage, or side channels, attackers can impersonate the host application, access protected resources, or decrypt sensitive data. This credential isolation requirement prevents scenarios where a compromised web page loaded in the embedded browser could steal the host's authentication credentials and use them for unauthorized access.

**Verification**:

1. Store test credentials/tokens in the host application's secure storage (keychain, keystore, credential manager) → Test that cryptographic operations using host keys cannot be triggered arbitrarily by web content
2. Load web content in the embedded browser → Host application credentials are completely isolated from web content
3. Attempt to access host credentials through various methods: JavaScript bridge APIs, localStorage inspection, cookie inspection, memory inspection → No JavaScript bridge API exposes credentials directly or indirectly
4. Verify that credentials stored by the host are isolated from web content storage → Web content storage (localStorage, cookies, IndexedDB) is separate from host credential storage
5. Test that shared storage mechanisms (if any) do not leak credentials → Shared storage mechanisms do not leak credentials
6. Attempt to extract credentials by triggering host application features that use them → Authentication tokens are not exposed in error messages or debug output
7. Verify that authentication tokens are not exposed in error messages or logs accessible to web content → Host cryptographic keys cannot be accessed or used arbitrarily by web content

**Pass Criteria**: Web content has no access to host credentials AND credential storage is completely isolated AND cryptographic keys are protected

**Fail Criteria**: Any credential or token is accessible to web content OR cryptographic keys can be misused

**Evidence**: Penetration test results, code review of credential storage isolation, test attempts to access credentials, memory dumps showing isolation, security audit reports

**References**:

- Android Keystore System: https://developer.android.com/training/articles/keystore
- iOS Keychain Services: https://developer.apple.com/documentation/security/keychain_services
- CWE-522: Insufficiently Protected Credentials: https://cwe.mitre.org/data/definitions/522.html

### Assessment: EMB-REQ-9 (JavaScript bridge security review)

**Reference**: EMB-REQ-9 - All JavaScript bridge implementations shall be reviewed for injection vulnerabilities before production deployment

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

**Task**: Security reviews for JavaScript bridge implementations are critical because bridges represent the most dangerous attack surface in embedded browsers, where improper input validation can lead to injection attacks, privilege escalation, or arbitrary code execution. Without formal security reviews, subtle vulnerabilities like SQL injection through bridge parameters, command injection in system-level APIs, or XSS through improperly sanitized return values can go undetected. Comprehensive security assessments by qualified professionals ensure that all bridge APIs are properly validated, sanitized, and protected against common attack vectors before they can be exploited in production.

**Verification**:

1. Obtain documentation of the security review process for JavaScript bridge implementations → Verify that third-party security assessments were conducted (if applicable)
2. Verify that a formal security code review was conducted before production deployment → Documented security review process exists for JavaScript bridge code
3. Review security assessment reports for the JavaScript bridge implementation → Security code reviews were conducted by qualified security professionals
4. Verify that common injection vulnerabilities were tested: SQL injection, command injection, path traversal, XSS, code injection → Common injection vulnerability types were specifically tested
5. Confirm that automated security scanning tools were used (static analysis, dynamic analysis) → Automated security scanning tools were applied
6. Verify that findings from security reviews were remediated before deployment → Security findings were tracked and remediated
7. Confirm that security reviews are repeated after significant bridge changes → Re-reviews occur after significant code changes

**Pass Criteria**: Formal security review was conducted AND injection vulnerabilities were specifically tested AND findings were remediated

**Fail Criteria**: No security review was conducted OR injection vulnerabilities were not tested OR findings were not remediated

**Evidence**: Security review reports, code review checklists, penetration test reports, static analysis tool outputs, vulnerability remediation tracking records, security sign-off documentation

**References**:

- OWASP Code Review Guide: https://owasp.org/www-project-code-review-guide/
- CWE Top 25 Most Dangerous Software Weaknesses: https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html
- NIST SP 800-53 - Security Assessment: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
- OWASP Mobile Application Security Verification Standard: https://github.com/OWASP/owasp-masvs

### Assessment: EMB-REQ-10 (Bridge API rate limiting)

**Reference**: EMB-REQ-10 - Host applications shall implement rate limiting on JavaScript bridge API calls to prevent abuse

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

**Task**: Rate limiting on JavaScript bridge APIs prevents abuse scenarios where malicious web content floods the bridge with excessive API calls to perform denial-of-service attacks, exhaust system resources, or brute-force security controls. Without rate limits, attackers can rapidly probe for vulnerabilities, overwhelm logging systems to hide their tracks, or cause performance degradation that impacts legitimate users. Proper rate limiting also prevents reconnaissance attacks where malicious scripts systematically enumerate all available APIs or attempt to bypass security controls through repeated high-frequency attempts.

**Verification**:

1. Identify rate limits for each JavaScript bridge API (requests per second, burst limits) → Rate limits are defined and documented for all bridge APIs
2. Create test scripts that invoke bridge APIs at high frequency → Excessive API calls are rejected or throttled
3. Verify that rate limits are enforced: excessive calls are rejected or throttled → Rate limit violations trigger security logging and alerts
4. Test that rate limit violations trigger logging and security alerts → Rate limits are enforced per-origin or per-context
5. Verify that rate limits are per-origin (different origins have independent quotas) → Rate limits reset on appropriate time boundaries
6. Test that rate limits reset appropriately (per second, per minute, per session) → Multiple contexts cannot bypass rate limits
7. Attempt to bypass rate limits by using multiple execution contexts (iframes, workers) → Legitimate high-frequency use cases are accommodated
8. Verify that legitimate use cases are not blocked by rate limits → Rate limit parameters are configurable by host application

**Pass Criteria**: Rate limits are enforced on all bridge APIs AND violations are logged AND limits cannot be bypassed

**Fail Criteria**: No rate limiting exists OR rate limits are bypassable OR legitimate use is blocked

**Evidence**: Rate limit configuration documentation, test results showing throttling behavior, security logs showing rate limit violations, performance test results

**References**:

- OWASP API Security - Rate Limiting: https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/
- CWE-770: Allocation of Resources Without Limits: https://cwe.mitre.org/data/definitions/770.html
- NIST SP 800-95: Guide to Secure Web Services: https://csrc.nist.gov/publications/detail/sp/800-95/final
- Rate Limiting Best Practices: https://cloud.google.com/architecture/rate-limiting-strategies-techniques

### Assessment: EMB-REQ-11 (Granular capability-based permissions)

**Reference**: EMB-REQ-11 - JavaScript bridges shall support granular capability-based permissions rather than all-or-nothing access

**Given**: A conformant embedded browser with advanced bridge capabilities (EMB-2 or higher)

**Task**: Granular capability-based permissions prevent over-privileged access scenarios where granting access to one API inadvertently exposes all bridge functionality to potentially malicious web content. All-or-nothing permission models force developers to choose between denying all access or granting excessive privileges, creating security risks. Fine-grained permissions enable the principle of least privilege, allowing each origin to access only the specific APIs it needs while preventing lateral movement attacks where compromise of one feature leads to unauthorized access to unrelated sensitive functionality.

**Verification**:

1. Review the permission model for the JavaScript bridge → Permission system supports individual API-level grants
2. Verify that permissions can be granted at individual API level rather than all-or-nothing → Different origins can have different permission sets
3. Test different permission configurations: grant some APIs but deny others to the same origin → Permissions can be scoped by time, usage count, or other constraints
4. Verify that capability tokens or permissions can be scoped by origin, time, or usage count → Temporary permissions expire as configured
5. Test that temporary permissions expire correctly → Permission grants and revocations are logged
6. Verify that permission grants are logged with full context → Users/administrators have control over granular permissions
7. Test that users or administrators can configure granular permissions → Default configuration follows least-privilege principle
8. Verify that the principle of least privilege is enforced by default → 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) → Test that malicious web content cannot pollute host storage namespace
2. Load web content and attempt to access host storage through web APIs (localStorage, IndexedDB, cookies) → Web content storage (localStorage, IndexedDB, cookies) is isolated from host native storage
3. Verify that web content cannot read native host storage → Host native storage is not accessible from web APIs
4. Store data in web content storage and attempt to access it from host application → Web storage is not directly accessible from host code (without explicit bridge)
5. Verify that host application code cannot directly access web storage without explicit bridge APIs → Multiple embedded browser instances have independent storage
6. Test that different embedded browser instances have isolated storage → Storage isolation is maintained even for same-origin content in different instances
7. Verify that clearing host application data does not affect web storage (unless explicitly configured) → Storage clearing operations are properly scoped

**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 → CSP policy is configurable by host application
2. Load web content and verify CSP is enforced: inline scripts blocked, external resource loading restricted → CSP is enforced for all embedded web content
3. Test that CSP violations trigger browser console errors and violation reports → Inline scripts, eval, and other dangerous features are blocked per policy
4. Verify that CSP cannot be bypassed by web content → CSP violations generate console errors and reports
5. Test that meta tag CSPs are respected but cannot weaken configured policy → Web content cannot bypass or weaken CSP policy
6. Verify that CSP applies to all content including iframes → CSP applies to all nested contexts (iframes)
7. Test CSP report-uri or report-to functionality → Violation reports are sent to configured endpoints
8. Verify that host application can configure CSP policy programmatically → 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 → Verify that encryption keys are securely managed and rotated
2. Verify that JavaScript bridge messages cross process boundaries → Multi-process architecture uses encrypted IPC for bridge messages
3. Analyze inter-process communication (IPC) mechanisms used for bridge messages → Bridge messages are not observable in plaintext during IPC
4. Verify that IPC channels are encrypted or use secure transport → Message integrity is cryptographically protected
5. Attempt to intercept bridge messages using debugging tools or IPC monitoring → Replay attacks are prevented through anti-replay mechanisms
6. Verify that message integrity is protected (authentication, MACs) → Encryption keys are properly generated and managed
7. Test that replay attacks are prevented (nonces, sequence numbers) → IPC interception does not reveal sensitive bridge data

**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 → Web content cannot trigger misleading native UI elements
2. Verify that all UI elements clearly identify their source (host app vs. web content) → All UI clearly indicates whether it originates from web content or host/OS
3. Test that web content cannot create UI elements that appear to be from the OS or host app → Permission prompts show the requesting origin clearly
4. Attempt clickjacking attacks using iframes and native UI → Clickjacking attempts are prevented by UI design
5. Verify that permission prompts clearly show the requesting origin → Rapid permission prompt abuse is prevented
6. Test that web content cannot programmatically trigger permission prompts in rapid succession → Native security indicators cannot be hidden or spoofed
7. Verify that native UI elements cannot be overlaid or obscured by web content → Fullscreen mode maintains critical security UI
8. Test that fullscreen mode does not hide native UI security indicators → 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 → JavaScript bridge uses allowlist-based access control
2. Verify that only explicitly registered APIs are accessible (allowlist approach) → Only explicitly allowlisted APIs are accessible from web content
3. Attempt to discover and call APIs that are not in the allowlist → APIs not in allowlist are not accessible regardless of denylist status
4. Test that new APIs require explicit registration before becoming accessible → New APIs require explicit allowlist registration
5. Verify that the absence of an API from a denylist does not make it accessible → Denylists (if present) are used only as an additional layer, not primary control
6. Review code to confirm allowlist-based access control logic → Reflection/introspection cannot discover non-allowlisted APIs
7. Test that reflection or introspection cannot enumerate unlisted APIs → Code review confirms allowlist-first architecture
8. Verify that the allowlist is the sole source of truth for API accessibility → 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 → Verify that pin backups exist to prevent lockout
2. Attempt to load content from a server with an invalid certificate (expired, self-signed, wrong hostname) → All HTTPS content undergoes full certificate validation
3. Verify that certificate validation errors block content loading → Invalid certificates block content loading
4. Test that user/host cannot bypass certificate errors for critical origins → Certificate errors generate clear error messages and logs
5. Configure certificate pinning for critical origins used by the application → Certificate pinning is enforced for configured critical origins
6. Attempt to use a valid but non-pinned certificate for a pinned origin → Pinning violations prevent content loading and trigger security events
7. Verify that pinning violations block content loading and trigger alerts → Backup pins exist to allow pin rotation without lockout
8. Test that certificate transparency information is validated → Certificate Transparency validation is performed

**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 → Origin allowlist is configured and documented
2. Attempt to load content from allowlisted origins and verify it loads successfully → Only allowlisted origins can load in the embedded browser
3. Attempt to load content from non-allowlisted origins and verify it is blocked → Non-allowlisted origins are blocked with appropriate error messages
4. Test redirect chains that exit allowlisted domains and verify they are blocked → Redirect chains exiting allowlisted domains are blocked
5. Verify that allowlist enforcement applies to main frame, iframes, and XHR/fetch requests → Allowlist applies to all resource types and contexts
6. Test that URL parameters or fragments cannot be used to bypass allowlist → URL manipulation cannot bypass allowlist enforcement
7. Verify that allowlist configuration is immutable by web content → Allowlist violations generate security events and logs
8. Test that allowlist violations trigger logging and security alerts → 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 → Test that the host application can enforce SRI policy via CSP require-sri-for directive
2. Add SRI integrity attributes to script tags: `<script src="..." integrity="sha384-..." crossorigin="anonymous">` → SRI integrity checking is enforced for external scripts
3. Verify that scripts with correct integrity hashes load successfully → Scripts with correct integrity hashes load and execute
4. Modify the external script content and verify that integrity validation fails and blocks execution → Scripts with incorrect or missing hashes are blocked per policy
5. Attempt to load scripts without integrity attributes from external origins and verify policy enforcement → SRI violations generate console errors and logs
6. Test that integrity validation applies to CSS, scripts, and other subresources → SRI applies to scripts, stylesheets, and other subresources
7. Verify that SRI failures trigger console errors and CSP violation reports → Host application can mandate SRI via CSP policy

**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 → Each pinned origin has at least one backup pin configured
2. Verify that at least one backup pin exists for each pinned origin → Primary and backup pins are both enforced correctly
3. Test that the primary pin is enforced correctly → Certificate rotation can occur using backup pins without lockout
4. Simulate primary certificate rotation and verify backup pin is accepted → Pin rotation procedures are documented and tested
5. Verify that pin rotation procedures are documented → Pin expiration/rotation schedules are reasonable
6. Test that pin expiration dates are configured appropriately (not too distant future) → Pin updates can be delivered via app updates or dynamic configuration
7. Verify that pin updates can be delivered to deployed applications → Total pin failure blocks connections rather than falling back to no pinning
8. Test fallback behavior when all pins fail (should block, not fall back to unpinned) → 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 → Verify that CSP upgrade-insecure-requests directive is supported
2. Attempt to load HTTP subresources from the HTTPS page: images, scripts, stylesheets, XHR, fetch → Active mixed content is always blocked
3. Verify that passive mixed content (images, media) is blocked or triggers warnings → Passive mixed content is blocked or triggers prominent warnings
4. Verify that active mixed content (scripts, stylesheets, iframes) is always blocked → Mixed content errors appear in browser console with details
5. Test that mixed content blocking cannot be disabled by web content → Web content cannot disable mixed content protection
6. Verify that host application cannot weaken mixed content protection → Host application cannot weaken mixed content blocking
7. Test that browser console shows clear mixed content errors → upgrade-insecure-requests CSP directive automatically upgrades HTTP to HTTPS

**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 → Verify log retention policies for security-relevant events
2. Load content from trusted and untrusted origins → All trust decisions are logged with sufficient detail
3. Review logs and verify they contain: origin, timestamp, trust decision outcome, reason for decision → Logs include origin, timestamp, decision, and rationale
4. Attempt trust boundary violations (untrusted origin accessing privileged APIs) → Trust boundary violations are logged with full context
5. Verify that violations are logged with full context → Certificate validation results are logged
6. Test that certificate validation decisions are logged → Origin allowlist enforcement is logged
7. Verify that origin allowlist enforcement is logged → Logs are protected from tampering
8. Test that logs are stored securely and cannot be tampered with by web content → Log retention balances security needs and privacy

**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) → All local/bundled content has cryptographic signatures
2. Verify that all bundled content is cryptographically signed → Signature verification occurs before content execution
3. Review signature verification implementation in the browser initialization code → Modified content fails signature verification
4. Attempt to modify bundled content and verify that signature verification fails → Signature verification failures block content loading
5. Test that signature verification failures prevent content loading → Secure signature algorithms are used
6. Verify that signature verification uses secure algorithms (RSA-2048+, ECDSA P-256+) → Signature verification cannot be bypassed
7. Test that signature verification cannot be bypassed or disabled → Signing keys are protected from extraction
8. Verify that signing keys are properly protected in the host application → 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 → Verify that JavaScript-based redirects are also subject to trust enforcement
2. Load a page from a trusted origin that redirects to another trusted origin → Redirect chain validation is enforced
3. Verify that trusted-to-trusted redirects are allowed → Trusted-to-trusted redirects are allowed
4. Load a page from a trusted origin that redirects to an untrusted origin → Any redirect to untrusted origin is blocked
5. Verify that trusted-to-untrusted redirects are blocked → Multi-hop redirect chains are fully validated
6. Test multi-hop redirect chains: trusted → trusted → untrusted → Both HTTP and JavaScript redirects are subject to enforcement
7. Verify that all redirects in the chain are validated against allowlist → Blocked redirects trigger error pages and security logs
8. Test that redirect blocking triggers security logging → Users are notified when redirects are blocked

**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` → HSTS headers are parsed and cached correctly
2. Make initial HTTPS request to trusted origin and verify HSTS header is received and cached → HTTP requests to HSTS hosts are automatically upgraded to HTTPS
3. Attempt to make HTTP request to same origin and verify automatic upgrade to HTTPS → HSTS state persists across browser sessions
4. Test that HSTS enforcement continues after browser restart (persistence) → includeSubDomains flag applies to all subdomains
5. Verify that HSTS includeSubDomains flag is respected for subdomains → HSTS preload list is maintained and enforced
6. Test that HSTS preload list is supported and enforced → HSTS cannot be bypassed through IP access or other means
7. Attempt to bypass HSTS through direct IP access or hosts file manipulation → Certificate errors on HSTS hosts are non-bypassable
8. Verify that certificate errors on HSTS hosts cannot be bypassed → 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 → Certificate validation failures are detected for all failure types
2. Simulate certificate validation failures: expired certificate, hostname mismatch, untrusted CA, revoked certificate → User receives immediate, clear error notification
3. Verify that each failure type triggers immediate error notification → Content loading is completely blocked on validation failure
4. Verify that content loading is completely blocked (no partial loading) → Error messages explain the specific certificate problem
5. Test that error notifications clearly explain the problem to users → No bypass mechanism exists for certificate errors on trusted origins
6. Verify that no "continue anyway" option exists for trusted origin failures → Certificate failures are logged with full details
7. Test that certificate failures are logged to security event log → Host application can register for certificate failure callbacks
8. Verify that host application is notified of certificate failures via callback → 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**: This assessment verifies that host applications implement declarative network security configurations (Android Network Security Config, iOS App Transport Security, or equivalent) that prevent cleartext HTTP traffic to trusted domains. Cleartext traffic exposes sensitive data to network eavesdropping and man-in-the-middle attacks. The configuration shall enforce HTTPS-only communication for trusted domains at the network layer, apply uniformly across all network APIs (WebView, XHR, fetch, WebSocket), integrate certificate pinning settings, be declarative and immutable at runtime (not modifiable by web content), and log blocked cleartext traffic attempts for security monitoring. Platform-specific security features shall be properly configured to prevent accidental or malicious downgrade to insecure HTTP connections.

**Verification**:

1. Review network security configuration files (Android NSConfig, iOS ATS) → Network security configuration enforces HTTPS-only for trusted domains
2. Verify cleartext HTTP traffic disabled for trusted domains → Cleartext HTTP traffic blocked at network layer
3. Attempt HTTP requests to trusted domains across all network APIs → HTTPS enforcement applies uniformly to all network APIs
4. Test runtime modification attempts of HTTPS enforcement → Configuration is declarative and immutable at runtime
5. Verify certificate pinning integration with network security config → Certificate pinning integrated into network security config
6. Test cleartext traffic blocking and verify logging → Blocked cleartext traffic is logged
7. Review configuration documentation and auditability → Configuration documented and auditable
8. Verify platform-specific security features properly utilized → Platform features (NSConfig, ATS) correctly configured

**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**: This assessment verifies that embedded browsers enforce Content Security Policy (CSP) to prevent trusted content from loading untrusted third-party resources without explicit declarations. Uncontrolled third-party content loading enables XSS attacks, data exfiltration, and supply chain compromises. The CSP shall restrict third-party content loading to explicitly allowlisted domains, apply uniformly to all resource types (scripts, styles, images, frames, etc.), report violations to configured endpoints, be immutable by web content, and have host-configured policies take precedence over page-specified CSP. Default CSP should be restrictive (deny by default), requiring explicit allowlisting for all third-party resources.

**Verification**:

1. Configure trusted content with restrictive CSP allowing specific third-party domains → CSP restricts third-party loading to explicitly allowed domains
2. Test loading from CSP-allowed domains and verify success → Allowed third-party content loads successfully
3. Attempt loading from non-allowed domains and verify blocking → Non-allowed third-party content is blocked
4. Test inline scripts from third-party content blocked unless CSP-allowed → CSP applies consistently across all resource types
5. Verify CSP applies to all resource types (scripts, styles, images, frames) → CSP violations generate reports to configured endpoint
6. Test CSP violations reported via report-uri or report-to → Web content cannot bypass or weaken CSP restrictions
7. Verify web content cannot weaken or disable CSP policy → Host-configured CSP cannot be overridden by page CSP
8. Test host-configured CSP takes precedence over page-specified CSP → CSP enforcement is logged and default policy is restrictive

**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**: This assessment verifies that embedded browsers support per-instance trust policy configuration, allowing each instance to enforce different security policies independently while maintaining complete isolation from other instances.

**Verification**:

1. Create multiple embedded browser instances within the same host application → Trust policies can be configured independently per instance
2. Configure different trust policies for each instance (different origin allowlists, certificate pins, CSP policies) → Each instance enforces its own trust policy correctly
3. Load content in each instance and verify that instance-specific policies are enforced → Instances are isolated from each other (no cross-instance access)
4. Verify that instances cannot access each other's storage or state → Trust policy configuration is scoped to individual instances
5. Test that trust policy configuration is isolated per instance → Instance creation accepts custom policy configuration
6. Attempt to modify one instance's trust policy from another instance → Instance destruction cleans up policy state
7. Verify that instance destruction cleans up trust policy state → No interference between instances' trust enforcement
8. Test that host application can dynamically create instances with custom policies → 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**: This assessment verifies that embedded browsers implement and enforce Certificate Transparency verification for trusted content origins, validating Signed Certificate Timestamps (SCTs) and blocking content from origins with missing or invalid SCTs.

**Verification**:

1. Configure trusted content origins that require Certificate Transparency → Certificate Transparency verification is supported
2. Load content from origins with valid SCTs (Signed Certificate Timestamps) in certificates or via TLS extension → Valid SCTs allow content loading from CT-required origins
3. Verify that content loads successfully when valid SCTs are present → Missing or invalid SCTs block content loading
4. Attempt to load content with certificates lacking SCTs from CT-required origins → SCTs are validated against known CT logs
5. Verify that missing or invalid SCTs block content loading for CT-required origins → CT enforcement policy is configurable (per-origin or global)
6. Test that SCTs are validated against known CT logs → CT validation failures generate clear error messages and logs
7. Verify that CT enforcement can be configured per-origin or globally → CT log list is kept up-to-date
8. Test that CT validation failures are logged → 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**: This assessment verifies that embedded browsers detect and prevent DNS rebinding attacks targeting trusted local and internal origins through DNS caching, Host header validation, and logging of rebinding attempts.

**Verification**:

1. Identify local/internal origins accessed by the embedded browser (localhost, 127.0.0.1, private IP ranges, .local domains) → DNS rebinding attacks are detected
2. Simulate DNS rebinding attack: external domain initially resolves to attacker IP, then rebinds to local/internal IP → Unexpected DNS resolution changes trigger blocking
3. Verify that DNS rebinding is detected and blocked → Private IP address access requires explicit configuration
4. Test DNS cache behavior and TTL enforcement → DNS cache prevents rapid rebinding
5. Verify that private IP address access requires explicit allowlisting → Host header validation is enforced
6. Test that DNS resolution results are validated against expected address ranges → Resolution results are validated against address allowlists
7. Verify that Host header validation prevents rebinding exploitation → Rebinding attempts are logged as security events
8. Test that DNS rebinding attempts trigger security logging → 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**: This assessment verifies that trust boundary violations trigger comprehensive security events with sufficient context for incident response, including proper distinction from general logs, SIEM integration capability, and alert generation for high-severity violations.

**Verification**:

1. Configure security event logging for the embedded browser → Trust boundary violations generate security events
2. Trigger various trust boundary violations (accessing blocked origins, calling restricted APIs, certificate validation failures, CSP violations) → Events include comprehensive context: timestamp, type, origin, description, severity
3. Review generated security events and verify they contain timestamp, event type, origin/source, detailed description, severity level, stack trace/context → Events are distinguishable from general logs (separate channel or marked)
4. Verify that security events are distinct from general application logs → Events can be exported or forwarded to security monitoring systems
5. Test that security events can be forwarded to SIEM or security monitoring systems → High-severity events trigger immediate alerts
6. Verify that high-severity violations trigger immediate alerts → Events include actionable information for incident response
7. Test that security events include sufficient context for incident investigation → Event logging is reliable and does not impact app stability
8. Verify that event generation does not disrupt application functionality → 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/

### Assessment: EMB-REQ-33 (Block web content access to host application objects at EMB-0)

**Reference**: EMB-REQ-33 - Embedded browser shall prevent all web content access to host application objects at EMB-0 capability level

**Given**: A conformant embedded browser with EMB-0 capability (no JavaScript bridge or native API exposure)

**Task**: At EMB-0 capability, embedded browsers shall completely isolate web content from host application objects, methods, and data structures to prevent JavaScript injection attacks, host context manipulation, and privilege escalation. Allowing any bridge interface, custom JavaScript objects, or window property injection at this level contradicts the security posture of complete isolation, enabling malicious web content to escape sandbox boundaries and compromise the host application. Complete object isolation with no window augmentation, strict namespace separation, and frozen global scope ensures zero native access.

**Verification**:

1. Load untrusted web content in the embedded browser → All common bridge object names undefined
2. Attempt to access common JavaScript bridge object names (AndroidBridge, webkit, chrome, nativeInterface, etc.) and verify they are undefined → Window object contains only standard web platform APIs
3. Enumerate window object properties and confirm no host-injected objects exist → No host-injected properties in global scope
4. Test reflection APIs (Object.keys, Object.getOwnPropertyNames) on window and verify no custom properties → Reflection APIs show only standard properties
5. Attempt to override native JavaScript methods and verify host does not expose overridden methods → Native method overrides not exploitable for host communication
6. Test for custom event listeners added by host and confirm none exist → No custom event listeners from host
7. Attempt to access parent/opener contexts and verify they are inaccessible or null → Parent/opener contexts inaccessible
8. Verify window.external is undefined or blocked (legacy IE bridge interface) → window.external undefined or blocked
9. Test for prompt/alert/confirm hijacking that would allow host communication → Dialog APIs do not create host communication channels
10. Verify no custom URL schemes trigger host-side callbacks at EMB-0 → Custom URL schemes do not trigger host callbacks

**Pass Criteria**: All bridge objects undefined AND window object contains only standard APIs AND no host-injected properties AND no communication channels exist

**Fail Criteria**: Bridge objects accessible OR custom window properties present OR host communication possible OR custom schemes trigger callbacks

**Evidence**: JavaScript console enumeration of window properties, reflection API output showing standard APIs only, bridge access attempt logs showing errors, URL scheme handler testing, dialog API interaction verification

**References**:

- OWASP Mobile WebView Security: https://mas.owasp.org/MASTG/tests/android/MASVS-PLATFORM/MASTG-TEST-0028/
- Android WebView addJavascriptInterface: https://developer.android.com/reference/android/webkit/WebView#addJavascriptInterface(java.lang.Object,%20java.lang.String)
- iOS WKWebView Script Message Handlers: https://developer.apple.com/documentation/webkit/wkusercontentcontroller
- Electron Context Isolation: https://www.electronjs.org/docs/latest/tutorial/context-isolation

### Assessment: EMB-REQ-34 (No JavaScript bridge exposure at EMB-0)

**Reference**: EMB-REQ-34 - No JavaScript bridge or native API exposure mechanism shall exist at EMB-0 capability level

**Given**: A conformant embedded browser with EMB-0 capability (no JavaScript bridge or native API exposure)

**Task**: JavaScript bridges create privileged communication channels between web content and native host applications, fundamentally violating EMB-0's isolation requirement. Any bridge mechanism - addJavascriptInterface (Android), WKScriptMessageHandler (iOS), contextBridge (Electron), or custom implementations - enables web content to invoke native methods, access host data, and potentially execute arbitrary code in the native context. At EMB-0, all bridge registration APIs should be disabled, configuration immutable, and attempted bridge creation blocked to ensure complete isolation.

**Verification**:

1. Review embedded browser initialization code and verify no bridge registration calls present → No addJavascriptInterface calls in Android WebView initialization
2. Test Android WebView addJavascriptInterface and confirm the API is not called or is blocked → No WKScriptMessageHandler registered in iOS WKWebView
3. Test iOS WKWebView addScriptMessageHandler and verify no handlers are registered → Electron contextBridge not exposed to renderer
4. Verify Electron contextBridge is not exposed in renderer preload scripts → Runtime bridge registration attempts fail
5. Attempt to register custom bridge handlers at runtime and verify registration fails → window.external undefined or non-functional
6. Test legacy bridge mechanisms (window.external, custom protocol schemes) and confirm they are disabled → Custom protocol scheme handlers do not create bridge channels
7. Verify embedded browser configuration prevents dynamic bridge creation → Configuration prevents dynamic bridge creation
8. Review application code for bridge-related APIs and confirm none are used → Application code audit shows no bridge APIs used
9. Test that web content cannot trigger native method invocation through any mechanism → Web content cannot invoke native methods
10. Verify security logs show zero bridge registration or access attempts → Security logs confirm zero bridge activity

**Pass Criteria**: No bridge registration APIs called AND runtime bridge creation blocked AND no legacy bridge mechanisms AND web-to-native invocation impossible

**Fail Criteria**: Bridge APIs called OR dynamic registration possible OR legacy bridges functional OR native invocation succeeds

**Evidence**: Source code review showing no bridge registration, runtime bridge attempt logs showing failures, WebView/browser configuration showing bridge disabled, security log analysis showing zero bridge activity, web content isolation testing

**References**:

- Android WebView JavaScript Interface Security: https://developer.android.com/reference/android/webkit/WebView#addJavascriptInterface(java.lang.Object,%20java.lang.String)
- iOS WKWebView Message Handlers: https://developer.apple.com/documentation/webkit/wkscriptmessagehandler
- Electron Context Isolation: https://www.electronjs.org/docs/latest/tutorial/context-isolation
- OWASP WebView Security: https://mas.owasp.org/MASTG/tests/android/MASVS-PLATFORM/MASTG-TEST-0028/

### Assessment: EMB-REQ-35 (Treat all content as untrusted at EMB-0)

**Reference**: EMB-REQ-35 - Embedded browser shall treat all loaded content as completely untrusted at EMB-0 capability level

**Given**: A conformant embedded browser with EMB-0 capability (no JavaScript bridge or native API exposure)

**Task**: At EMB-0, embedded browsers shall apply maximum security restrictions to all web content regardless of source origin, loading mechanism, or content type, treating even application-bundled content as potentially malicious. Trusting any content source creates privilege escalation risks where attackers who compromise trusted origins gain disproportionate access. Universal untrusted treatment with strict CSP enforcement, feature policy restrictions, and capability lockdown ensures consistent security posture across all content, preventing attackers from exploiting trust assumptions to escape isolation boundaries.

**Verification**:

1. Load content from application bundle resources and verify same security restrictions as remote content → Bundled content has same restrictions as remote content
2. Test application-bundled HTML/JS and confirm no privileged access granted → No privileged access for application resources
3. Load content from localhost and verify it receives no special treatment → Localhost receives no elevated privileges
4. Test file:// protocol content and confirm strict security policies applied → file:// content strictly restricted
5. Verify Content Security Policy enforced uniformly for all content sources → CSP applied uniformly to all sources
6. Test that bundled content cannot access host APIs unavailable to remote content → Host APIs equally inaccessible from all origins
7. Verify feature policy restrictions apply equally to all origins → Feature policies enforced consistently
8. Load same content from different sources (bundle, localhost, remote) and verify identical API availability → API availability identical across content sources
9. Test that no "trusted origin" configuration grants elevated privileges at EMB-0 → No trusted origin exceptions at EMB-0
10. Verify permission prompts (if any) appear for all content regardless of source → Permission requirements uniform across origins

**Pass Criteria**: All content sources treated identically AND no privileged access for bundled content AND CSP enforced uniformly AND no trusted origin exceptions

**Fail Criteria**: Bundled content has elevated privileges OR localhost trusted OR file:// bypasses restrictions OR trusted origins exist

**Evidence**: Content source comparison testing showing identical restrictions, CSP policy verification across sources, API availability enumeration by source, bundled content security analysis, trusted origin configuration audit

**References**:

- Android WebView Local Content Security: https://developer.android.com/develop/ui/views/layout/webapps/webview#local-content
- Content Security Policy: https://www.w3.org/TR/CSP3/
- Feature Policy: https://www.w3.org/TR/permissions-policy-1/
- OWASP WebView Best Practices: https://mas.owasp.org/MASTG/tests/android/MASVS-PLATFORM/MASTG-TEST-0028/

### Assessment: EMB-REQ-36 (Allowlist-only bridge API access at EMB-1)

**Reference**: EMB-REQ-36 - Only explicitly allowlisted APIs shall be accessible from web content at EMB-1 capability level

**Given**: A conformant embedded browser with EMB-1 capability (limited JavaScript bridge with explicit allowlist)

**Task**: This assessment verifies that JavaScript bridge implementations use explicit allowlisting to expose only pre-approved, security-reviewed APIs to web content, with runtime enforcement that blocks reflection-based attacks, dynamic invocation exploits, and unintended API exposure. The assessment confirms that bridge objects are immutable from web context, reflection APIs either show only allowlisted methods or are blocked entirely, and comprehensive API inventory documentation exists to prevent undocumented API access and host compromise.

**Verification**:

1. Review JavaScript bridge configuration and document complete allowlist of exposed APIs → Allowlisted APIs documented comprehensively
2. Attempt to invoke API methods not in the allowlist and verify calls are blocked with errors → Non-allowlisted method calls blocked with errors
3. Use reflection APIs in JavaScript to enumerate bridge object methods → Reflection shows only allowlisted methods or is blocked
4. Verify reflection returns only allowlisted methods (or reflection is blocked entirely) → Dynamic invocation limited to allowlist
5. Test dynamic invocation (bridge[methodName]()) and confirm only allowlisted methods callable → Prototype chain not exploitable for API discovery
6. Attempt to access bridge object prototype and verify it's not exploitable for additional access → Method name matching is strict
7. Test method name variations (case changes, encoding) and verify strict matching enforced → Bridge object immutable from web context
8. Attempt to add methods to bridge object at runtime and verify it's immutable → API additions require native code changes
9. Test that bridge API additions require host application code changes and cannot be made from web content → No undocumented APIs accessible
10. Verify documentation and implementation match (no undocumented APIs accessible) → Security review documentation exists for all allowlisted APIs

**Pass Criteria**: Only allowlisted APIs accessible AND reflection blocked or limited AND dynamic invocation restricted AND bridge immutable from web