Window-specific security principle
To strengthen security, each window should be granted only the minimum necessary capabilities and plugin functionality required for that window to function.
security & best practices
30 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
WebView process security best practices
Security best practices apply to WebView processes: you must always sanitize user input, never handle secrets in the Frontend, and ideally defer as much business logic as possible to the Core process to keep your attack surface small.
Principle of Least Privilege in process isolation
The multi-process architecture applies the Principle of Least Privilege by limiting the blast radius of potential exploits. Only the minimum amount of permissions necessary for each process to function is granted. The WebView process should not have full OS access, reducing harm if compromised.
Principle of least privilege in multi-process design
Each process should be granted only the minimum permissions necessary to complete its job. This principle limits the impact of potential vulnerabilities and reduces damage from compromise.
Business logic should reside in core process
To minimize the attack surface, as much business logic as possible should be delegated to the core process rather than the frontend. The frontend should always sanitize user input and never handle sensitive information.
Tauri 2.0 security audit approach
Tauri 2.0 will undergo a security audit with external auditors, following the same approach used for Tauri 1.0 in collaboration with Radically Open Security. The security audit findings must be resolved before moving to the Release Candidate phase.
Tauri philosophy: local-first applications
Tauri allows building local-first applications without a webserver, enabling users to keep their data private without sharing it with third parties.
Tauri security audit
The entire Tauri project has been horizontally and vertically audited by an independent third party, with the audit report available at https://github.com/tauri-apps/tauri/blob/dev/audits/Radically_Open_Security-v1-report.pdf
Key dependency updates in Tauri 1.1.0
Tauri 1.1.0 includes important dependency updates: windows updated to 0.39.0, webview2-com updated to 0.19.1, and raw-window-handle updated to 0.5.0. Apps implementing platform-specific functionalities using these crates must update. Related plugins such as window-vibrancy and window-shadows should also be updated to latest.
Security vulnerability in fs.readDir with symlinks
Tauri 1.1.0 includes a security patch for a vulnerability in the readDir function that was able to return entries outside the configured scope when a symlink is found. This patch is also available in Tauri 1.0.6. The issue was reported by martin-ocasek.
File dialog path escaping security vulnerability in Tauri 1.2.0
A security vulnerability existed in Tauri due to incorrect escaping of special characters in paths selected via file dialog and drag and drop functionality. This could partially bypass the fs scope definition, but was limited to neighboring files and subfolders of already allowed paths. Exploitation required a user to select a pre-existing malicious file or directory during the file picker dialog and required adversary-controlled logic to access these files. The patch was available in versions 1.0.7, 1.1.2, and 1.2.0.
External API access configuration for remote IPC
Tauri 1.3 introduces dangerousRemoteUrlIpcAccess in the security configuration to allow specified subdomains to gain remote access to the Tauri IPC layer. The configuration allows scoping by windows, domain, plugins, and optionally disabling the Tauri API. Domains must be fully trusted and shared domains must not be used. Domain ownership change over the application lifetime could lead to compromised devices. Access is scoped only to specified subdomains, not to paths or specific files.
Bundler handlebars content escaping fix
Tauri 1.3 fixed a security issue where the bundler was not escaping content passed to handlebars::Handlebars::render(), which could have caused unwanted code execution during the bundler phase.
ZipSlip vulnerability fix in bundler
Tauri 1.3 fixed a potential ZipSlip vulnerability where components extracting remote bundler files used ZipFile::name() instead of ZipFile::enclosed_name(), which could have allowed files with names like ../../../../foo.sh to be extracted outside of the intended directory. The implementation was changed to use the proper extraction method.
Browser arguments feature restricted to Rust side
The additional_browser_args option for creating windows was changed to be only exposed on the Rust side in Tauri 1.3. Tauri application developers can use this to implement custom commands to invoke webview windows with use case specific arguments. This feature is Windows-only and was restricted because exposing it to the frontend presented a security risk due to dangerous webview features accessible via process arguments.
dangerousRemoteUrlIpcAccess configuration example
Example security configuration for external IPC access: ```json "security": { "dangerousRemoteUrlIpcAccess": [ { "windows": ["main", "settings"], "domain": "trusted.example", "plugins": ["trusted-plugin"], "enableTauriAPI": false }, ], } ```
Security audit findings for Tauri 1.4.0
An internal security audit was performed during the Tauri 1.4.0 release cycle. A selection of PRs labeled as security-reviewed were manually audited instead of all PRs. The audit discovered one impactful security issue (CVE-2023-34460) which was fixed in a subsequent security patch release.
Tauri v2 undergoing security audit
Tauri v2 is undergoing a security audit to ensure safety, similar to the audit conducted for the v1 stable release.
Security advisory CVE-2024-35222
A security advisory CVE-2024-35222 was discovered in Tauri 2 beta, which motivated changes to the Rust API surface. A security patch was announced and distributed. All findings from the external audit were fixed in multiple beta versions.
External security audit completion and report
Tauri 2.0 completed an external security audit funded by NLnet and conducted by RadicallyOpenSecurity. The full audit report was made available at the RC stage at https://github.com/tauri-apps/tauri/blob/dev/audits/Radically_Open_Security-v2-report.pdf. All issues discovered were fixed and retested.
External security audit of Tauri 2.0
Tauri 2.0's major changes and architecture were independently audited by Radically Open Security during the beta and release candidate period. The audit was funded by NLNet via funding from NGI. The audit results led to rewrites of how the dev server is exposed for mobile development, hardening of iFrame API exposure, fixes to scope validation and resource identifier access for the fs and http plugins, and improved inter-process communication stability.
HTTP headers in Tauri 2.1.0+ defined in security config
As of Tauri 2.1.0, HTTP headers can be defined in the security section of the configuration file. Headers defined in the configuration are sent with responses to the webview. This includes all responses sent through the get_response function in crates/tauri/src/protocol/tauri.rs, but does not include IPC (inter-process communication) messages or error responses.
Tauri-Custom-Header not intended for production use
The Tauri-Custom-Header is not intended for production use. When using Tauri-Custom-Header in tests, remember to properly set the Access-Control-Expose-Headers header.
Timing-Allow-Origin permits Resource Timing API access
The Timing-Allow-Origin header permits scripts loaded from listed web sites to access detailed network timing data via the Resource Timing API.
Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy enable SharedArrayBuffer
Setting Cross-Origin-Opener-Policy to 'same-origin' and Cross-Origin-Embedder-Policy to 'require-corp' permits the use of SharedArrayBuffer in the webview.
CSP is separate from HTTP headers configuration
Content Security Policy (CSP) is not defined in the HTTP headers section. CSP is defined separately in the 'csp' field within the security configuration, not in the 'headers' field.
Tauri configuration example for HTTP headers
Example HTTP headers configuration in src-tauri/tauri.conf.json: ```json { "app":{ "security": { "headers": { "Cross-Origin-Opener-Policy": "same-origin", "Cross-Origin-Embedder-Policy": "require-corp", "Timing-Allow-Origin": [ "https://developer.mozilla.org", "https://example.com" ], "X-Content-Type-Options": null, "Access-Control-Expose-Headers": "Tauri-Custom-Header", "Tauri-Custom-Header": { "key1": "'value1' 'value2'", "key2": "'value3'" } }, "csp": "default-src 'self'; connect-src ipc: http://ipc.localhost" } } } ``` Note that CSP is defined separately from HTTP headers.
HTTP header value formats in Tauri configuration
HTTP headers in Tauri configuration can be specified as: a string (resulting header value remains identical), an array of strings (resulting header values have elements joined with ', '), an object with key-value pairs where values are strings (resulting header values have each key-value pair formatted as 'key value' joined with '; '), or null (header is ignored). Null values cause the header to be skipped.
Allowed HTTP header names in Tauri security config
The following header names are allowed in Tauri's security configuration: Access-Control-Allow-Credentials, Access-Control-Allow-Headers, Access-Control-Allow-Methods, Access-Control-Expose-Headers, Access-Control-Max-Age, Cross-Origin-Embedder-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, Permissions-Policy, Timing-Allow-Origin, X-Content-Type-Options, and Tauri-Custom-Header. The Tauri-Custom-Header is not intended for production use.
Command developers must ensure scopes cannot be bypassed
Command developers are responsible for ensuring that scope evasion is not possible. Scope validation implementation must be audited to ensure its correctness.