[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).

[gknapp]

Where does this stand in V2 at present? I thought there might be a way to do this via the tauri::Builder but I've not come across any example code. I'd like to add the machine hostname, and users of my app can add trusted server locations to fetch resources.

At present this is blocked by the CSP. I do not know the hostnames at compile time, when installed the machine hostname will change and the user should be able to use trusted hosts.

[FabianLars]

i can't answer your actual question, but for a workaround you could modify the tauri config before the tauri::Builder line like this https://github.com/tauri-apps/tauri-plugin-localhost?tab=readme-ov-file#usage (v1 example but should be roughly the same for v2)

[gknapp]

Thanks, I was able to insert the machine name using that method.

As for user specified hosts, I may end up doing something clunky, requiring an app restart. Writing the hosts to disk, reading that on app start and add those in at this point too.

Here's how I went about the former:

New csp.rs module:

use tauri::Config;

pub fn get_system_hostname() -> Result<String, String> {
  hostname::get()
    .map_err(|e| format!("Failed to get hostname: {}", e))?
    .into_string()
    .map_err(|_| "Hostname contains invalid UTF-8".to_string())
}

pub fn update_csp_with_hostname(config: &Config, hostname: &str) -> Result<String, String> {
  let base_csp = config.app.security.csp.as_ref()
    .ok_or("No CSP found in config")?.to_string();

  let host_directives = ["connect-src", "script-src", "frame-src"];
  let host_pattern = format!(" http://{}:* https://{}:*", hostname, hostname);
  
  let updated_csp = base_csp.split(';')
    .map(|d| {
      let d = d.trim();
      if host_directives.iter().any(|&prefix| d.starts_with(prefix)) {
        format!("{}{}", d, host_pattern)
      } else {
        d.to_string()
      }
    })
    .collect::<Vec<_>>()
    .join("; ");

  Ok(updated_csp)
}

Modifications to main.rs:

use tauri::utils::config::Csp;

mod csp;

// tauri commands ...

fn main() {
  let hostname = match csp::get_system_hostname() {
    Ok(h) => h,
    Err(e) => {
        eprintln!("Warning: Failed to get hostname: {}", e);
        "localhost".to_string()
    }
  };

  let mut context = tauri::generate_context!();
    
  if let Ok(new_csp) = csp::update_csp_with_hostname(context.config(), &hostname) {
    println!("Dynamic CSP: {}", new_csp);
    context.config_mut().app.security.csp = Some(Csp::Policy(new_csp));
  }

  tauri::Builder::default()
    // register plugins, invoke_handler, setup ...
    .run(context)
    .expect("error while running tauri application");
}