[feat] allow changing the CSP before it gets injected into the webview

[lucasfernog]

Describe the problem

Some applications needs to connect to user-provided URLs, and to keep it secure, Tauri should allow developers to extend the CSP string at runtime.

Describe the solution you'd like

Add a runtime API to change the CSP string.

Alternatives considered

No response

Additional context

No response

[tweidinger]

This feature has a lot of implications security wise.
If we allow to change the CSP at runtime by calling APIs from the frontend, the security boundary will become no longer clear.
This probably relates to similar changes required to allow user defined paths to be accessible for the fs endpoints.
Imho creating a configuration file, where additional paths/domains can be modified should be investigated.

[JonasKruckenberg]

If we allow to change the CSP at runtime by calling APIs from the frontend, the security boundary will become no longer clear.

This is a good concern, but changing the CSP at runtime is a no-go IMO.
We can make it a method on the AppBuilder struct (maybe once_cell?) that would still allow dynamic CSPs, while not giving up security in the process.

Imho creating a configuration file, where additional paths/domains can be modified should be investigated.

Wdym by this exactly?

[tweidinger]

This is a good concern, but changing the CSP at runtime is a no-go IMO.

Fully agree at the current state.

Wdym by this exactly?

We currently face multiple issues where the allowlist is configured at compile time but cannot be changed by user interaction during use/runtime.

For example the fs scoping needs to be aware of user defined paths (example: image library with user defined library paths). The http scope also has some usability issues, where in certain cases it is required to let the application user define domains after installation (example: federated web application with unknown server domains at compile time).

The same goes for the CSP but imho the CSP should be the last thing to improve, as this (fetching data from user defined sources) should ideally be handled by the rust backend.

So having an inbuilt configuration storage (some kind of authenticated and/or encrypted file/db), which is persistent in the filesystem, could improve the above uses cases, where application users would be able to "safely" extend allow functions, depending on their use case.

I think this is just a possible solution and more discussion around this topic would be awesome.
The approach of having a security relevant configuration introduces additional attack surface but could
encourage the proper usage of the allow list scoping.
For example the proposed security model would easily break if the fs api could write to the configuration.

[lucasfernog]

This feature has a lot of implications security wise. If we allow to change the CSP at runtime by calling APIs from the frontend, the security boundary will become no longer clear. This probably relates to similar changes required to allow user defined paths to be accessible for the fs endpoints. Imho creating a configuration file, where additional paths/domains can be modified should be investigated.

We won't allow changing it from the frontend, just on the Rust side on initialization.

[tweidinger]

That sounds like a reasonable trade off for now, as it doesn't break the current security assumptions (you are not constrained by the tauri config on the rust side at all).