[feat] Allow to completely sandbox WebViews from network access

[Frando]

Describe the problem

I want to create Tauri windows (WebViews) that run user supplied code ("apps"). I enabled a custom protocol handler (via register_uri_scheme_protocol). However, currently the WebViews can still access the other by-default enabled protocols (e..g. http, https, and tauri) and, for example, change the window location or issue fetch requests.

Describe the solution you'd like

I'd like these WebViews to be completely sandboxed and disallow all communication but the custom protocol handler that I registered. Ideally, I want to allow-list protocols for the WebView and disallow everything that is not in the allowlist, for all means of communication (window.location, fetch, XmlHttpRequest, <script scr="..."> etc).

Ideally, I want a WebView that defaults to no protocols, then specifically allow protocols, and additionally have a simple hook (in rust) that is run for all network/protocol requests that can abort or disallow the request.

Alternatives considered

There are a few ways to reduce communication surface for a WebView currently:

• Setting a strict CSP policy. This already, I think, allows to disallow most communication for a WebView.
• The isolation feature provides a way to intercept and disallow IPC communication for WebViews
• The WebViewBuilder in wry has a with_navigation_handler that, I think, would allow to disallow navigating away from the allowed protocol, however I don't think this is currently exposed in tauri?

It might be possible to completely sandbox a WebView this way. If that is a case, a documentation guide for a completely sandboxed and secured WebView would be useful. However, it feels a bit hacky to get a sandboxed webview by tying together multiple hooks to disallow things. I'd prefer to enable a "sandbox" mode or something once that would disallow all network communication by default, and then selectively enable things. This would, I think, be the better security primitive to run user-supplied code without having to fear information extraction attacks.

Additional context

No response

[JonasKruckenberg]

I like this idea, further restricting the available channels seems very reasonable. However, I don't think we can disable the default protocols. At least on macOS WKWebView ships a set of default protocols that you simply cannot override. It will actually trigger an objc exception if you try to override it, causing a rust panic.
I'm not aware of alternative constructors for the webview that create a "no defaults" Webview. But if there are this feature request would be very good to have!

[JonasKruckenberg]

Update: So WKWebView doesn't let you omit default protocols. But you can add custom content rules theoretically. Then you would just a catch-all rule that blocks all requests.

Relevant resources:

https://developer.apple.com/documentation/webkit/wkusercontentcontroller/2902756-add

https://developer.apple.com/documentation/safariservices/creating_a_content_blocker

[FabianLars]

What i had in mind when we talked about it on Discord was webkitgtk's PolicyDecision stuff

[WofWca]

I'll share our experience of (an atempt at?) implementing a sandboxed WebView.

In out application, https://github.com/deltachat/deltachat-desktop, there is a feature called webxdc. This is basically "mini-apps" built into the messenger. They communicate with the core app over custom commands, and we need these apps not to be able to access internet, and do any other evil stuff. You can read more about sandboxing in this blog post https://delta.chat/en/2023-05-22-webxdc-security, and this security audit.
We already have an Electron implementation of it, but we're doing a Tauri rewrite of the Delta Chat messenger.

So, here is the list of things we do:

• Set up a dummy TCP listener and use it as a SOCKS proxy for the to-be-isolated WebViews, using WevViewBuilder::proxy_url (our code).
• Set a strict CSP on all possible HTTP responses (our code).
• Disable navigation to other domains (our code).
• For Chromium (Windows WebView2), disable MIME sniffing and make sure to never serve application/pdf, against PDF viewer CSP bypass (our code 1, 2).
• For Chromium (Windows), basically disable WebRTC using --webrtc-ip-handling-policy=disable_non_proxied_udp in combination with --proxy-server (our code).
• For Chromium (Windows), disable DNS prefetch exfiltration by using --host-rules="MAP * ~NOTFOUND" and --host-resolver-rules.
• For Chromium (Windows) there was another trick of disabling WebRTC by creating 500 RTCPeerConnection objects (in all <iframe>s!!), which is the upper limit in Chromium per process, but we haven't implemented it in Tauri because we decided that what we have is enough. See this section in the blog post I mentioned. See also our Electron code for it. This method might stop working soon because of the IsolateSandboxedIframes Chromium feature.
• Again disable WebRTC (on all platforms this time) by overriding the globalThis.RTCPeerConnection constructor (in all <iframe>s, and as early as possible!!). (our code (MR))
• Disable developer tools (against phishing for data exfiltration) (our code).
• On macOS, disable long-press link preview (our code (MR)).
• Disable all commands by default, using AppManifest (our code).
• Disable all custom scheme protocols for the webview that needs to be isolated, by explicitly checking webview label inside the custom scheme protocol handler (our code sample).

We test the webxdc isolation implementation using the "Test Webxdc" app and Wireshark. See the instructions in this MR webxdc/webxdc-test#40.

We are awaiting another security audit of our Tauri implementation within a month.
Update 2025-09-18: the audit didn't test the exfiltration aspect of our implementation too thoroughly, but at least it didn't find ways in which a sandboxed window can affect other processes (main, other windows).