Is it possible in anyway to have cross-site scripting attacks in tauri

[vednig]

I was reviewing csp and cookies, I couldn't figure out a way that allows cross-site scripting attacks via JS(anyway atleast) with tauri.
If not then inlinejs could be default in Tauri, providing a much better dx.

[tweidinger]

Hey, I am a little bit confused about your goal? Do you want to change the default CSP? Do you want to change the example CSP from our security docs?

The default CSP value in Tauri is null which means no CSP is enabled or enforced by default (which may change in the future).
The CSP example in our security docs does allow a little bit more than just the absolute minimum but no unsafe-inline except for styles.

Speaking about XSS (cross site scripting), that it is an attack vector we assume and considered when building Tauri. Our security model tries to empower developers to only provide the absolute minimum permissions to the frontend code in term of system access. Since Tauri does support basically all common frontend frameworks and vanilla JavaScript it is entirely possible to have XSS attacks in Tauri apps. It all depends on how well the frontend sanitizes and validates user provided input.

A compromised frontend via XSS has the same API Access exposed to the window. Impact depends on exposed APIs.

[vednig]

From my understanding XSS are usually tested by bad actors if url queries are directly injecting something, but since Tauri in prod is not available as accessible url from the browser, there seems to be no way for bad actors to inject code(in prod) and Inspect is also disabled.

[tweidinger]

It would have been easy for developers to deploy their web apps directly as Tauri Apps, if inline js was default. I understand and agree with the decision for CSP.

What do you mean? Where? The default CSP is none which means you can do inline js by default as there is no restriction at all.

[tweidinger]

From my understanding XSS are usually tested by bad actors if url queries are directly injecting something, but since Tauri in prod is not available as accessible url from the browser, there seems to be no way for bad actors to inject code(in prod) and Inspect is also disabled.

Simplified example (inspired from our plugin api example but modified to make it vulnerable and simple ):

1. Assume if another application writes into the clipboard or your user pasted something into it that contains an XSS payload.
2. Your application renders clipboard content by using something like insecureRenderHtml or just plain dom manipulation in vanilla JS (not using setTextContent or similar).
3. XSS

 const text = await clipboard.readText()
 insecureRenderHtml('<p>'+ text + '</p>')

The security and likelihood of XSS soley depends on your implementation and frontend framework. Tauri has nothing to do with this directly and can not prevent XSS itself.

[vednig]

> The default CSP is none which means you can do inline js by default

https://csp-evaluator.withgoogle.com/ states none is not a security directive, also at least on windows that means no inline JS

[tweidinger]

With none (which is acutally null as in my first answer) I meant the configuration value in tauri.conf.json which means there will be no CSP header set by Tauri.