Android BitBox bridge sets AllowUniversalAccessFromFileURLs / AllowFileAccess on a hidden WebView that never loads a file URL

[jim-daf]

BitBoxBridgeModule.startServer() (android/app/src/main/java/ch/swissbitcoinpay/checkout/BitBoxBridgeModule.java) takes the hidden sbp_bitbox_webview created by SBPBitboxContext.android.tsx and adds:

vw.getSettings().setJavaScriptEnabled(true);
vw.getSettings().setAllowUniversalAccessFromFileURLs(true);
vw.getSettings().setAllowFileAccess(true);

A few lines later it attaches JavascriptBridge (addJavascriptInterface(new JavascriptBridge(), JAVASCRIPT_INTERFACE)) which forwards JS messages to Mobileserver.backendCall, so anything that ends up running inside that WebView reaches BitBox internals.

The hidden WebView is created from the React Native side as:

<Webview
  ref={ref}
  androidWebviewId="sbp_bitbox_webview"
  source={{ html: \"\" }}
  ...
  onMessage={onMessage}
/>

so its origin is never file://. setAllowFileAccess(true) only matters once the WebView lands on a file URL, and setAllowUniversalAccessFromFileURLs(true) is a known sandbox-escape vector flagged by Google's Android documentation (CWE-200): it lets a file:// page issue XHR against any other origin, including app-private files. Neither flag is needed by this flow.

If the WebView ever did need to load a packaged asset (e.g. the BitBox JS shipped with the app), the supported alternative today is WebViewAssetLoader over shouldInterceptRequest, which serves the asset under an https origin without flipping either flag on.

Suggested change

Delete the two setAllow... lines. The default values are already correct for what this WebView does. On API 30+ both flags default to false anyway, but on older devices they default to true unless explicitly turned off, so dropping the toggle tightens the posture on those devices while not changing behaviour on modern ones.

A PR with the two-line removal is open at #363.