EN-304-617.md

5. Test microphone access from installed PWA and confirm runtime permission required → Filesystem permissions not granted at install
6. Attempt geolocation access and verify user should explicitly grant consent → Permission management UI shows no auto-grants
7. Test filesystem access and confirm permission prompt required at runtime → Installation flow does not include permission bundling
8. Review browser permission management UI and verify no permissions granted at install time → Install and permission actions are separate
9. Test that PWA installation flow does not include bundled permission consent → All permissions require post-install runtime consent
10. Verify installation UI separates "install app" from "grant permissions" actions → Users can install PWA and deny all permissions

**Pass Criteria**: Installation grants no permissions AND all APIs require runtime consent AND installation UI separate from permission granting

**Fail Criteria**: Any permissions auto-granted at install OR APIs accessible without runtime prompts OR installation bundles permission consent

**Evidence**: PWA installation flow screenshots, post-install permission status checks, API access tests showing permission prompts, permission management UI state, installation logs

**References**:

- Web App Manifest: https://www.w3.org/TR/appmanifest/
- Permissions API: https://www.w3.org/TR/permissions/
- PWA Installation: https://web.dev/install-criteria/

### Assessment: SYS-REQ-38 (PWA uninstallation permission revocation)

**Reference**: SYS-REQ-38 - PWA uninstallation shall revoke all granted permissions at SYS-2 capability level

**Given**: A conformant browser with SYS-2 capability supporting Progressive Web Applications

**Task**: When users uninstall Progressive Web Applications, all previously granted permissions shall be immediately revoked to prevent residual access to device capabilities, storage, and user data. If permissions persist after uninstallation, uninstalled malicious PWAs could retain background notification access, maintain filesystem handles, preserve authentication tokens, or continue data collection through background sync. Complete permission revocation with persistent storage clearing, credential removal, and registration cleanup ensures uninstallation fully removes PWA capabilities.

**Verification**:

1. Install a PWA and grant it multiple permissions (camera, microphone, notifications, location) → All permissions revoked after uninstall
2. Document all granted permissions through browser permission management interface → Camera access no longer available
3. Verify PWA has active notification subscriptions and background sync registrations → Microphone permissions removed
4. Test that PWA has access to persistent storage, service workers, and cached data → Notification subscriptions cancelled
5. Uninstall the PWA through browser UI → Background sync registrations removed
6. Immediately after uninstall, check permission management UI to verify all permissions revoked → Service workers unregistered
7. Attempt to access previously granted APIs and verify they are no longer accessible → Persistent storage cleared
8. Verify notification subscriptions are cancelled and no notifications delivered → IndexedDB data removed or inaccessible
9. Check that service workers are unregistered and no longer run in background → Cache storage cleared
10. Verify persistent storage, IndexedDB, and cache storage are cleared or inaccessible → No residual PWA capabilities remain

**Pass Criteria**: All permissions revoked on uninstall AND service workers unregistered AND persistent storage cleared AND no residual access

**Fail Criteria**: Any permissions remain after uninstall OR service workers continue running OR storage persists OR notifications still delivered

**Evidence**: Permission status before and after uninstall, service worker registration logs, storage inspection showing cleared data, notification delivery tests, background sync status checks

**References**:

- Service Workers: https://www.w3.org/TR/service-workers/
- Storage API: https://storage.spec.whatwg.org/
- Push API: https://www.w3.org/TR/push-api/
- Background Sync: https://wicg.github.io/background-sync/spec/

### Assessment: SYS-REQ-39 (PWA permission audit logging)

**Reference**: SYS-REQ-39 - Browser shall maintain audit log of all PWA permission grants and revocations at SYS-2 capability level

**Given**: A conformant browser with SYS-2 capability supporting Progressive Web Applications

**Task**: Comprehensive audit logging of PWA permission lifecycle events enables security monitoring, forensic analysis, compliance verification, and attack detection. Without detailed logs of permission grants, revocations, installation, and uninstallation events, organizations cannot detect suspicious permission requests, identify compromised applications, investigate security incidents, or demonstrate regulatory compliance. Tamper-resistant audit logs with timestamps, origin identification, permission types, and user actions provide accountability and security visibility.

**Verification**:

1. Enable audit logging in browser configuration (if optional) or verify it is enabled by default → Installation events logged with timestamp and origin
2. Install a PWA and grant it camera and microphone permissions → Permission grants recorded per API type
3. Review audit logs and verify they contain installation event with timestamp and origin → User actions (grant/deny) captured in logs
4. Check logs for permission grant events showing camera and microphone with user action recorded → Permission revocations logged with details
5. Revoke microphone permission through browser settings → Uninstallation events recorded
6. Verify revocation event logged with timestamp, permission type, and user/admin action → All revocations on uninstall documented
7. Uninstall the PWA completely → Logs include complete metadata (time, origin, permission, action)
8. Confirm uninstallation event appears in logs with all associated permission revocations → Logs protected from tampering
9. Test that logs include sufficient detail: timestamp, origin, permission type, user action, result → Enterprise admins can export and analyze logs
10. Verify logs are protected from tampering by application code or unauthorized access → Log retention policy documented and enforced

**Pass Criteria**: All PWA permission events logged AND logs include complete metadata AND logs protected from tampering AND retention policy enforced

**Fail Criteria**: Permission events not logged OR logs lack critical metadata OR logs can be tampered with OR no retention policy

**Evidence**: Audit log exports showing permission lifecycle events, log integrity verification, log access control testing, retention policy documentation, log format analysis

**References**:

- Audit Logging Best Practices: https://owasp.org/www-community/Log_Injection
- NIST Audit Logging: https://csrc.nist.gov/publications/detail/sp/800-92/final
- Browser Security Logging: https://chromium.googlesource.com/chromium/src/+/master/docs/security/audit-logging.md

### Assessment: SYS-REQ-40 (Enterprise PWA permission policy controls)

**Reference**: SYS-REQ-40 - Enterprise administrators shall be able to configure PWA permission policies at SYS-2 capability level

**Given**: A conformant browser with SYS-2 capability supporting Progressive Web Applications and enterprise policy management

**Task**: Enterprise environments require centralized control over PWA capabilities to enforce organizational security policies, prevent data exfiltration, comply with regulations, and manage risk. Without enterprise policy controls, users can install PWAs that violate corporate security standards, access sensitive device APIs, persist beyond management, or bypass security monitoring. Group policy integration with allowlist/blocklist controls, forced permission denials, and audit requirements enables IT administrators to govern PWA security posture.

**Verification**:

1. Access browser enterprise policy configuration interface (Group Policy, MDM, policy JSON) → Policy blocks non-allowlisted PWA installations
2. Configure policy to block PWA installation from all origins except allowlisted domains → Camera permissions enforced denied by policy
3. Attempt to install PWA from non-allowlisted origin and verify installation is blocked → Audit logging requirement cannot be bypassed
4. Configure policy to deny camera permissions for all PWAs enterprise-wide → Storage quotas enforced per policy
5. Install allowed PWA and attempt camera access, verifying it is blocked by policy → Specific capabilities blocked as configured
6. Configure policy requiring audit logging for all PWA permission events → Policy overrides user preferences
7. Verify audit logging is enforced and cannot be disabled by users → Policy overrides PWA manifest permissions
8. Test policy to set maximum storage quota for PWAs → Centralized policy management available
9. Configure policy blocking specific PWA capabilities (background sync, notifications) → Policy violations logged to enterprise monitoring
10. Verify policy overrides user preferences and PWA manifest requests → Users cannot circumvent policy restrictions

**Pass Criteria**: Enterprise policies enforced AND allowlist/blocklist controls work AND permission denials override user grants AND policy violations logged

**Fail Criteria**: Policies not enforced OR users can bypass restrictions OR PWAs override policy OR no violation logging

**Evidence**: Policy configuration documentation, installation blocking tests, permission denial verification, audit logs showing policy enforcement, user bypass attempt results, policy override testing

**References**:

- Chrome Enterprise Policies: https://chromeenterprise.google/policies/
- Firefox Enterprise Policies: https://github.com/mozilla/policy-templates
- Microsoft Edge Policies: https://docs.microsoft.com/en-us/deployedge/microsoft-edge-policies
- Mobile Device Management: https://www.w3.org/TR/app-manifest/#controlling-installation

### Assessment: SYS-REQ-41 (Native-equivalent API access controls at SYS-3)

**Reference**: SYS-REQ-41 - Browser shall allow native-equivalent API access with user consent at SYS-3 capability level

**Given**: A conformant browser with SYS-3 capability (native-equivalent system access)

**Task**: At SYS-3 capability, browsers enable native-equivalent API access for advanced web applications requiring deep system integration, but this access should require explicit, informed user consent to prevent abuse. Native-equivalent APIs may include direct filesystem access, arbitrary USB/serial device communication, advanced Bluetooth capabilities, or system command execution, creating significant security risks if granted without user understanding. Clear consent flows with risk warnings, per-API authorization, revocability, and audit trails balance functionality with security.

**Verification**:

1. Identify native-equivalent APIs available at SYS-3 (File System Access API, WebUSB, Serial API, etc.) → Native-equivalent APIs require consent prompts
2. Attempt to access File System Access API and verify user consent prompt appears with clear warnings → Prompts include clear risk warnings
3. Test that consent prompt explains the risks and capabilities being granted → Per-API authorization required
4. Grant consent and verify API access is enabled for the origin → Permissions can be revoked through settings
5. Revoke permission through browser settings and verify API access is blocked → WebUSB requires per-device consent
6. Test WebUSB device access and confirm per-device consent prompts appear → Serial API requires per-port authorization
7. Verify consent for one USB device does not grant access to all devices → Enhanced Bluetooth requires additional consent
8. Test Serial API access and confirm user should explicitly authorize each serial port → All API usage logged comprehensively
9. Attempt Bluetooth access beyond standard Web Bluetooth scope and verify enhanced consent required → Consent prompts indicate SYS-3 privilege level
10. Verify all native-equivalent API usage logged for security auditing → Users can deny access without breaking basic web functionality

**Pass Criteria**: Native-equivalent APIs gated by consent AND prompts include risk warnings AND per-API authorization AND permissions revocable AND usage logged

**Fail Criteria**: APIs accessible without consent OR prompts lack risk warnings OR blanket authorization granted OR permissions not revocable

**Evidence**: Consent prompt screenshots with risk warnings, permission grant/revoke testing, API access logs, per-device authorization verification, permission management UI analysis

**References**:

- File System Access API: https://wicg.github.io/file-system-access/
- WebUSB API: https://wicg.github.io/webusb/
- Web Serial API: https://wicg.github.io/serial/
- Permissions API: https://www.w3.org/TR/permissions/

### Assessment: SYS-REQ-42 (Transparent UI for native integration at SYS-3)

**Reference**: SYS-REQ-42 - Browser shall provide transparent UI for all native integration features at SYS-3 capability level

**Given**: A conformant browser with SYS-3 capability (native-equivalent system access)

**Task**: Users shall have complete visibility into which web applications have native-equivalent capabilities, what system resources they access, and when access occurs, enabling informed decisions and security awareness. Without transparent UI, malicious applications can silently access filesystem, devices, or system APIs without user knowledge, facilitating data theft, surveillance, and system compromise. Comprehensive UI with active access indicators, permission management interfaces, usage history, and clear capability explanations ensures user awareness and control.

**Verification**:

1. Grant filesystem access to a web application through File System Access API → Active filesystem access indicator visible
2. Verify browser UI displays active indicator when application accesses filesystem → Permission management UI lists all native capabilities
3. Access browser permission management interface and verify it lists all granted native capabilities → Capabilities explained in clear language
4. Test that permission UI clearly explains each granted capability in user-friendly language → Usage history accessible and detailed
5. Verify browser provides usage history showing when and how native APIs were accessed → USB access shows active indicator
6. Test active USB device access and confirm browser shows indicator (icon, notification, or status) → Serial connections display connection status
7. Open serial port connection and verify browser displays active connection indicator → Indicators link to detailed information
8. Test that users can click indicators to view details about active native API usage → Users can revoke permissions through UI
9. Verify permission management UI allows users to view, modify, and revoke native capabilities → Revocation immediately effective and reflected in UI
10. Test that revoking permission immediately stops API access and updates UI → No native access occurs without UI visibility

**Pass Criteria**: Active access indicators visible AND permission management comprehensive AND usage history available AND revocation through UI functional

**Fail Criteria**: No access indicators OR permission UI incomplete OR no usage history OR revocation not available

**Evidence**: Active indicator screenshots during API usage, permission management UI documentation, usage history exports, indicator interaction testing, revocation workflow verification

**References**:

- User Interface Security: https://www.w3.org/TR/security-privacy-questionnaire/
- Browser UI Design: https://chromium.googlesource.com/chromium/src/+/master/docs/ui/
- Permission UX Best Practices: https://web.dev/permissions-ux/

### Assessment: SYS-REQ-43 (Security warnings for privileged API access at SYS-3)

**Reference**: SYS-REQ-43 - Browser shall display security warnings for privileged API access at SYS-3 capability level

**Given**: A conformant browser with SYS-3 capability (native-equivalent system access)

**Task**: Privileged API access at SYS-3 grants capabilities equivalent to native applications, including filesystem access, device control, and system integration, requiring prominent security warnings to prevent user confusion and social engineering attacks. Without clear warnings, users may not understand the security implications of granting native-equivalent access, enabling attackers to gain persistent filesystem access, device control, or system-level privileges through deceptive prompts. Warning UI with risk explanations, consequences, and alternatives helps users make informed security decisions.

**Verification**:

1. Trigger File System Access API permission request from a web application → Filesystem access prompts include clear warnings
2. Verify permission prompt includes clear security warning about filesystem access risks → Warnings explain read/write capabilities and risks
3. Confirm warning explains that the site will gain ability to read/write files directly → USB prompts warn about device control implications
4. Test WebUSB permission prompt and verify it warns about device control risks → USB warnings note firmware access potential
5. Confirm USB warning explains potential for device firmware access and modification → Serial API warnings explain hardware communication risks
6. Trigger Serial API permission and verify warning about direct hardware communication → Warnings visually distinct from standard prompts
7. Test that warnings are visually distinct (color, icons, prominence) from normal permission prompts → Dismissal requires deliberate user action
8. Verify warnings cannot be easily dismissed or bypassed through rapid clicking → Explicit risk acknowledgment required
9. Test that warnings require explicit "I understand the risks" acknowledgment → Warnings shown on first and periodic subsequent access
10. Verify warnings are shown on first access and periodically for ongoing privileged access → Warning language calibrated to user understanding level

**Pass Criteria**: Privileged APIs show security warnings AND warnings explain specific risks AND visual distinction from normal prompts AND explicit acknowledgment required

**Fail Criteria**: No warnings shown OR warnings lack risk details OR warnings visually identical to normal prompts OR easy bypass available

**Evidence**: Permission prompt screenshots with security warnings, warning text analysis, user interaction flow documentation, bypass attempt testing, warning frequency verification

**References**:

- Security Warning Design: https://www.usenix.org/conference/soups2019/presentation/reeder
- Effective Permission Prompts: https://web.dev/permission-ux/
- User Security Indicators: https://www.w3.org/TR/security-privacy-questionnaire/

### Assessment: SYS-REQ-44 (Extended system access audit logging at SYS-3)

**Reference**: SYS-REQ-44 - Browser shall log all extended system access for security auditing at SYS-3 capability level

**Given**: A conformant browser with SYS-3 capability (native-equivalent system access)

**Task**: Native-equivalent system access at SYS-3 creates significant security risk requiring comprehensive audit logging for attack detection, forensic investigation, compliance verification, and insider threat monitoring. Without detailed logs capturing filesystem access, device interactions, API usage patterns, and permission changes, organizations cannot detect data exfiltration, identify compromised applications, investigate security incidents, or meet regulatory audit requirements. Tamper-resistant logs with complete metadata enable security visibility and accountability.

**Verification**:

1. Enable or verify audit logging is active for SYS-3 capability level → All filesystem operations logged with paths
2. Grant filesystem access to a web application and access multiple files → USB device interactions logged comprehensively
3. Review audit logs and verify they contain entries for each file access with path, operation, timestamp → Serial port access and data transmission recorded
4. Connect and communicate with a USB device through WebUSB → Permission changes logged with full context
5. Verify logs capture device connection, data transfer, and disconnection events → Logs include complete metadata for each event
6. Open serial port connection and transmit data → Log entries are timestamped with high precision
7. Confirm logs document serial port access, configuration, and data transmission → Logs protected from tampering or deletion
8. Revoke a permission through browser settings → Enterprise administrators can export logs
9. Verify permission revocation logged with timestamp, origin, and permission type → Log retention meets security and compliance needs
10. Test that logs include complete metadata: timestamp, origin, API, resource, operation, result, user context → Logs integrate with SIEM and security monitoring tools

**Pass Criteria**: All extended system access logged AND logs include complete metadata AND tamper protection enforced AND enterprise export available

**Fail Criteria**: System access not logged OR logs lack critical metadata OR logs can be tampered with OR no export capability

**Evidence**: Audit log exports showing system access events, log completeness verification, tamper protection testing, SIEM integration demonstration, retention policy documentation

**References**:

- Security Audit Logging: https://csrc.nist.gov/publications/detail/sp/800-92/final
- Browser Security Logs: https://chromium.googlesource.com/chromium/src/+/master/docs/security/audit-logging.md
- SIEM Integration: https://owasp.org/www-community/Log_Injection

### Assessment: SYS-REQ-45 (User permission review and revocation at SYS-3)

**Reference**: SYS-REQ-45 - Users shall be able to review and revoke all system permissions at SYS-3 capability level

**Given**: A conformant browser with SYS-3 capability (native-equivalent system access)

**Task**: Users shall have complete visibility and control over all granted system permissions to manage their security posture, respond to threats, and maintain privacy. Without comprehensive permission review and revocation interfaces, users cannot identify over-privileged applications, remove access from compromised sites, or recover from accidental permission grants. Centralized permission management with per-origin listings, granular revocation, usage visibility, and immediate enforcement enables user control and security hygiene.

**Verification**:

1. Grant multiple system permissions (filesystem, USB, serial, notifications) to various web origins → All granted permissions visible in management UI
2. Navigate to browser permission management interface → Permissions organized by origin and type
3. Verify interface displays all granted permissions organized by origin and permission type → High-privilege permissions clearly marked
4. Test that interface clearly identifies high-privilege permissions (filesystem, device access) → Individual permission revocation functional
5. Select a permission and revoke it through the management interface → Revocation takes effect immediately
6. Immediately test that the web application can no longer access the revoked resource → Applications receive permission denial after revocation
7. Verify error or permission denial shown to application after revocation → Bulk revocation available per origin
8. Test bulk revocation of all permissions for a specific origin → Usage history shown for each permission
9. Confirm all permissions removed and application loses all system access → No hidden or unrevocable permissions exist
10. Verify permission management UI shows usage history for each permission → Interface accessible and user-friendly

**Pass Criteria**: All permissions visible in management UI AND individual revocation functional AND immediate enforcement AND usage history available

**Fail Criteria**: Permissions not listed OR revocation doesn't work OR delayed enforcement OR no usage visibility

**Evidence**: Permission management UI screenshots, revocation testing showing immediate effect, usage history exports, bulk revocation verification, hidden permission audit

**References**:

- Permissions API: https://www.w3.org/TR/permissions/
- Permission Management UX: https://web.dev/permission-ux/
- Browser Privacy Controls: https://www.w3.org/TR/privacy-controls/

### Assessment: SYS-REQ-46 (Enterprise restriction of native-equivalent features at SYS-3)

**Reference**: SYS-REQ-46 - Enterprise administrators shall be able to restrict native-equivalent features at SYS-3 capability level

**Given**: A conformant browser with SYS-3 capability supporting native-equivalent system access and enterprise policy management

**Task**: Enterprise environments require centralized control to restrict native-equivalent features that pose unacceptable risk to organizational security, intellectual property, or compliance requirements. Without enterprise policy controls, users at SYS-3 can grant unrestricted filesystem access, device control, or system integration to web applications, enabling data exfiltration, malware installation, or regulatory violations. Group policy integration with capability blocking, origin restrictions, and forced denials enables IT security governance.

**Verification**:

1. Access enterprise policy configuration interface (Group Policy, MDM, policy JSON) → File System Access API blocked by policy
2. Configure policy to block File System Access API organization-wide → Policy blocks API with clear error message
3. Attempt to use File System Access API as user and verify policy blocks access with clear error → WebUSB restricted to allowlisted origins
4. Configure policy to allow WebUSB only for specific allowlisted origins → Non-allowlisted origins denied device access
5. Test WebUSB from non-allowlisted origin and verify policy denies access → Allowlisted origins function normally
6. Test WebUSB from allowlisted origin and verify it functions → Serial API completely disabled by policy
7. Configure policy to completely disable Serial API → Administrator approval workflow enforced
8. Attempt serial port access and verify it is blocked by policy → Users cannot bypass policy restrictions
9. Configure policy requiring administrator approval for any SYS-3 capability grants → Policy violations logged to enterprise monitoring
10. Test that user permission grants require admin authorization workflow → Policies centrally managed and enforced

**Pass Criteria**: Enterprise policies block native-equivalent features AND origin allowlists enforced AND administrator approval available AND policy violations logged

**Fail Criteria**: Policies not enforced OR users bypass restrictions OR allowlists ignored OR no violation logging

**Evidence**: Policy configuration documentation, API blocking verification, origin allowlist testing, admin approval workflow demonstration, policy bypass attempt results, violation logs

**References**:

- Chrome Enterprise Policies: https://chromeenterprise.google/policies/
- Firefox Enterprise Policies: https://github.com/mozilla/policy-templates
- Microsoft Edge Policies: https://docs.microsoft.com/en-us/deployedge/microsoft-edge-policies
- Enterprise Browser Management: https://www.chromium.org/administrators/

### Assessment: SYS-REQ-47 (Native integration audit documentation at SYS-3)

**Reference**: SYS-REQ-47 - All native integration exceptions shall be documented and auditable at SYS-3 capability level

**Given**: A conformant browser with SYS-3 capability (native-equivalent system access)

**Task**: Native integration exceptions that deviate from standard web security model shall be comprehensively documented to enable security review, vulnerability assessment, compliance auditing, and risk management. Without documentation of security boundaries relaxed, APIs exposed beyond web standards, or sandbox exceptions granted, security teams cannot assess risk posture, auditors cannot verify compliance, and developers cannot understand security implications. Architecture documentation with threat models, exception justifications, and mitigation controls enables informed security governance.

**Verification**:

1. Review browser security documentation to identify documented native integration exceptions → Native integration exceptions fully documented
2. Verify documentation explains each exception's purpose, risks, and mitigations → Documentation explains purpose, risks, and mitigations
3. Confirm documentation includes threat model for native-equivalent API surface → Threat models available for native APIs
4. Review code comments and design documents for File System Access API implementation → Implementation aligns with documentation
5. Verify implementation matches documented security model and exception handling → Runtime information available about active integration
6. Test that browser provides runtime information about active native integration (developer tools, about:security) → Enterprise admin documentation comprehensive
7. Verify enterprise administrators can access detailed documentation of native features → Audit logs align with documented behavior
8. Review security audit logs and confirm they align with documented native integration behavior → No undocumented exceptions exist
9. Test that documented exceptions are the only ones present (no undocumented backdoors) → Documentation kept current with releases
10. Verify documentation is maintained and updated with browser releases → Security review process documented

**Pass Criteria**: All exceptions documented AND documentation includes threat models AND implementation matches documentation AND no undocumented exceptions

**Fail Criteria**: Exceptions not documented OR no threat models OR implementation deviates OR undocumented exceptions found

**Evidence**: Security documentation review, threat model analysis, code implementation verification, runtime security interface examination, audit log alignment testing, exception enumeration

**References**:

- Secure Development Lifecycle: https://www.microsoft.com/en-us/securityengineering/sdl/
- Threat Modeling: https://owasp.org/www-community/Threat_Modeling
- Security Documentation: https://cheatsheetseries.owasp.org/cheatsheets/Security_Documentation_Checklist.html

## 6.8 Embedded Browser Security Assessments

This section covers assessment procedures for requirements EMB-REQ-1 through EMB-REQ-32, addressing the unique security challenges of embedded browsers (WebView components, browser engines integrated into native applications). These assessments focus on JavaScript bridge security, native API exposure control, content source trust management, and host application boundary protection.

### Assessment: EMB-REQ-1 (JavaScript bridge API allowlists)

**Reference**: EMB-REQ-1 - JavaScript bridges shall implement explicit allowlists of exposed native APIs with per-API access controls

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

**Task**: JavaScript bridges expose native device APIs to web content, creating critical attack surfaces where unrestricted API exposure enables privilege escalation, data exfiltration, malware installation, and complete device compromise. Without explicit allowlists, malicious web content can invoke any native API through reflection or dynamic invocation. Explicit API allowlisting with per-API access controls, runtime immutability, reflection blocking, and comprehensive logging prevents bridge-based attacks while enabling controlled native functionality.

**Verification**:

1. Review the embedded browser's JavaScript bridge configuration and implementation code → Verify that the bridge logs all API access attempts including denied attempts
2. Identify all native APIs exposed to web content through the JavaScript bridge → JavaScript bridge exposes only explicitly allowlisted native APIs
3. Verify that an explicit allowlist mechanism exists (configuration file, API declaration, or programmatic registration) → Configuration files or code clearly declare which APIs are accessible
4. Attempt to call native APIs that are not in the allowlist from web content → Per-API access controls restrict which origins or contexts can call each API
5. Verify that per-API access controls exist (e.g., origin-based restrictions, permission requirements) → Attempts to call non-allowlisted APIs result in errors or exceptions
6. Test that the allowlist cannot be modified by web content at runtime → Web content cannot modify the API allowlist at runtime
7. Attempt to use reflection or dynamic invocation to bypass the allowlist → Reflection or dynamic method invocation does not bypass allowlist enforcement

**Pass Criteria**: Only explicitly allowlisted APIs are callable from web content AND per-API access controls are enforced AND allowlist cannot be modified by web content

**Fail Criteria**: Any non-allowlisted API is callable OR access controls are bypassable OR web content can modify the allowlist

**Evidence**: JavaScript bridge configuration files, implementation code review, test results showing blocked API calls, security logs showing denied access attempts, penetration test reports

**References**:

- OWASP Mobile Top 10 - M1: Improper Platform Usage: https://owasp.org/www-project-mobile-top-10/
- Android WebView addJavascriptInterface Security: https://developer.android.com/reference/android/webkit/WebView#addJavascriptInterface(java.lang.Object,%20java.lang.String)
- iOS WKWebView Configuration: https://developer.apple.com/documentation/webkit/wkwebviewconfiguration
- Electron Context Bridge: https://www.electronjs.org/docs/latest/api/context-bridge
- CWE-749: Exposed Dangerous Method or Function: https://cwe.mitre.org/data/definitions/749.html

### Assessment: EMB-REQ-2 (JavaScript bridge input validation)

**Reference**: EMB-REQ-2 - All data crossing the JavaScript bridge shall be validated, sanitized, and type-checked on the native side

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

**Task**: JavaScript bridge parameters originate from untrusted web content and can contain injection payloads, type confusion attacks, buffer overflows, path traversal sequences, or prototype pollution that exploit native code vulnerabilities. Without comprehensive validation, attackers can achieve SQL injection into native databases, command injection for arbitrary code execution, or path traversal to access sensitive files. Native-side validation with type checking, sanitization, range checking, and path canonicalization prevents injection attacks across the trust boundary.

**Verification**:

1. Identify all native APIs exposed via JavaScript bridge that accept parameters → All bridge API parameters undergo validation on the native side before processing
2. For each API, review the native-side validation and sanitization logic → Type checking rejects parameters of incorrect types
3. Create test cases with malicious inputs: SQL injection strings, path traversal sequences, command injection payloads, excessively long strings, null bytes, Unicode exploits → String sanitization removes or escapes dangerous characters
4. Invoke bridge APIs with malformed data: wrong types, missing parameters, extra parameters, null values, undefined values → Numeric parameters are range-checked
5. Attempt to pass JavaScript objects with prototype pollution characteristics → File paths are validated and canonicalized
6. Test that numeric parameters are range-checked and validated → Malicious inputs trigger validation errors without causing security issues
7. Verify that file paths are canonicalized and validated before use → Validation failures are logged with sufficient detail for security monitoring
8. Confirm that validation failures trigger errors and logging rather than silent failures → No SQL injection, command injection, or path traversal vulnerabilities exist

**Pass Criteria**: All bridge parameters are validated, sanitized, and type-checked AND malicious inputs are rejected safely AND validation failures are logged

**Fail Criteria**: Any injection vulnerability exists OR type checking is missing OR validation can be bypassed

**Evidence**: Code review showing validation logic, penetration test results, fuzzing test results, validation error logs, security assessment reports

**References**:

- OWASP Input Validation Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
- CWE-20: Improper Input Validation: https://cwe.mitre.org/data/definitions/20.html
- CWE-89: SQL Injection: https://cwe.mitre.org/data/definitions/89.html
- CWE-78: OS Command Injection: https://cwe.mitre.org/data/definitions/78.html
- Android WebView Security Best Practices: https://developer.android.com/develop/ui/views/layout/webapps/webview#security

### Assessment: EMB-REQ-3 (JavaScript bridge logging)

**Reference**: EMB-REQ-3 - JavaScript bridge communications shall be logged with sufficient detail for security auditing

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

**Task**: JavaScript bridge logging is critical for detecting and investigating attacks where malicious web content attempts to exploit native APIs through the bridge. Without comprehensive audit logs, security teams cannot detect unauthorized API access, track attack patterns, or investigate security incidents. Proper logging of all bridge communications enables security monitoring systems to identify suspicious patterns such as repeated failed API calls, attempts to access restricted functionality, or unusual parameter values that may indicate injection attacks or reconnaissance activities.

**Verification**:

1. Configure the embedded browser to enable JavaScript bridge logging → Confirm log retention policies are documented and enforced
2. Invoke various bridge APIs from web content → All JavaScript bridge API invocations are logged
3. Review the generated logs and verify they contain: API name, timestamp, calling origin, parameters (with sensitive data redacted), return values, success/failure status → Logs include sufficient context for security analysis (API, origin, timestamp)
4. Attempt to call blocked or restricted APIs and verify denials are logged → Both successful and failed API calls are logged
5. Generate high-volume bridge traffic and verify logging continues without loss → Sensitive parameters are redacted or hashed in logs
6. Test that sensitive data (passwords, tokens) is redacted from logs → Logs are tamper-resistant with integrity protection
7. Verify logs are stored securely with appropriate access controls → Log retention policies balance security needs and privacy requirements

**Pass Criteria**: All bridge API calls are logged with sufficient detail AND sensitive data is redacted AND logs have integrity protection

**Fail Criteria**: API calls are not logged OR insufficient detail is recorded OR sensitive data appears in plaintext

**Evidence**: Log samples showing bridge API calls, log configuration files, security monitoring dashboards, 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-4 (Context isolation)

**Reference**: EMB-REQ-4 - Embedded browsers shall implement context isolation to prevent web content from accessing host application objects

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

**Task**: Context isolation is essential to prevent malicious web content from breaking out of its sandbox and directly accessing host application objects, which could lead to privilege escalation, data theft, or code execution in the host application context. Without proper isolation, attackers can enumerate the JavaScript global namespace to discover and exploit unintended host APIs, access sensitive application data structures, or manipulate host application behavior through prototype pollution. This boundary violation represents one of the most critical security threats in embedded browser architectures.

**Verification**:

1. Load web content in the embedded browser → Verify that iframes inherit context isolation from the parent
2. From web content JavaScript, attempt to access global objects that might belong to the host: `window.hostApp`, `window.native`, `window.android`, `window.nativeInterface`, etc. → Web content cannot access host application objects directly
3. Attempt to enumerate window properties to discover host-exposed objects → Global namespace pollution from host application is prevented
4. Test if web content can access Node.js globals (if applicable): `process`, `require`, `Buffer`, `global` → Node.js globals (if applicable) are not accessible to web content
5. Verify that the JavaScript bridge API is the only official communication channel → Only explicitly exposed JavaScript bridge APIs are accessible
6. Test that prototype pollution cannot affect host application objects → Window property enumeration does not reveal internal objects
7. Confirm that context isolation is enforced even for trusted content origins → Prototype pollution attacks do not affect host application

**Pass Criteria**: Web content has no direct access to host objects AND only official bridge APIs are accessible

**Fail Criteria**: Any host application object is directly accessible from web content OR context isolation can be bypassed

**Evidence**: Penetration test results showing blocked access attempts, code review of context isolation implementation, test scripts attempting to access host objects, browser console showing security errors

**References**:

- Electron Context Isolation: https://www.electronjs.org/docs/latest/tutorial/context-isolation
- Chromium Isolated Worlds: https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/bindings/core/v8/V8BindingDesign.md#Isolated-World
- iOS WKWebView JavaScript Isolation: https://developer.apple.com/documentation/webkit/wkwebview
- Android WebView Isolation: https://developer.android.com/reference/android/webkit/WebView

### Assessment: EMB-REQ-5 (User consent for sensitive APIs)

**Reference**: EMB-REQ-5 - Native APIs exposed via JavaScript bridges shall require explicit user consent for sensitive operations

**Given**: A conformant embedded browser exposing sensitive APIs via JavaScript bridge (EMB-2 or higher)

**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