Frontend asset extraction tooling planned
Tauri plans to provide tooling or make it easier to extract frontend assets from compiled binaries, allowing the use of security tools like npm audit on the extracted assets.
Tauri · Plugins and security · all subjects
security
48 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Web proxy interception for pentesting
Tauri currently has no built-in method to intercept webview traffic through testing proxies like Burpsuite, Zap, or Caido, but there is ongoing work to ease this process for security testing.
WebView sandboxing future work
Tauri plans to research and implement ways to further sandbox and isolate webview processes. Both built-in and external sandboxing methods will be evaluated to reduce attack impact and enforce the IPC bridge for system access, as the webview is identified as the weakest link in the stack due to its memory-unsafe implementation.
Fuzzing infrastructure development planned
Tauri aims to implement mock runtimes and tooling to make fuzzing easier for application developers, and to support existing libraries like libAFL to build Tauri-specific fuzzing frameworks, making fuzzing accessible and efficient across multiple operating systems and CPU architectures.
Binary analysis for security auditing
Tauri plans to provide tools and metadata in compiled binaries to enable pentesters, auditors, and automated security checks to audit applications without source code access, and to empower users to audit systems for known vulnerabilities at scale.
cargo-auditable for Rust SBOM generation
Tauri plans to use cargo-auditable to create Software Bill of Materials (SBOMs) and provide exact crate versions and dependencies of binaries without breaking reproducible builds. This allows security auditing without accessing source code.
Trust boundary definition in computer security
A trust boundary is a term used in computer science and security which describes a boundary where program data or execution changes its level of trust, or where two principals with different capabilities exchange data or commands.
Report Tauri security vulnerabilities via GitHub or email
If there is a security concern with Tauri or repositories in the Tauri organization, do not publicly comment on findings. The preferred disclosure method is via GitHub Vulnerability Disclosure on the affected repository, or via the Tauri repository at https://github.com/tauri-apps/tauri/security/advisories/new. Alternatively, contact the security team at security@tauri.app.
Tauri security model: trust boundaries between Rust core and WebView frontend
Tauri's security model differentiates between Rust code written for the application's core and frontend code written in any framework or language understood by the system WebView. Rust core and plugins have full access to all available system resources and are not constrained. WebView code has only access to exposed system resources via the IPC layer. Access to core application commands is configured and restricted by capabilities defined in the application configuration.
IPC layer enforces trust boundaries between Rust core and WebView
The IPC layer is the bridge for communication between Rust core and WebView frontend trust groups. It ensures that boundaries are not broken. Inspecting and strongly defining all data passed between boundaries is very important to prevent trust boundary violations. If data is passed without access control between these boundaries, it is easy for attackers to elevate and abuse privileges.
Capabilities configuration controls command access from WebView
Access to core application commands from the WebView is configured and restricted by capabilities defined in the application configuration. Individual command implementations enforce the optional fine-grained access levels also defined in the capabilities configuration.
Tauri does not bundle WebView; relies on operating system WebView
Tauri relies on the operating system WebView and does not bundle the WebView into the application binary. From a security perspective, the most important reason is that WebView packet maintainers and operating system packet maintainers are significantly faster to patch and roll out security patched WebView releases than application developers who bundle the WebView directly with their application.
Security is sum of Tauri, dependencies, application code, and device security
The security of a Tauri application is the sum of the overall security of Tauri itself, all Rust and npm dependencies, the application code, and the devices that run the final application.
Reproducible builds for verifying build integrity
To combat backdoor injection at build time, builds need to be reproducible so that build assets can be verified to be exactly the same when built locally or on another independent provider.
Consume critical dependencies from git with hash revisions
A recommended practice is to only consume critical dependencies from git using hash revisions at best, or named tags as second best. This practice applies to both Rust and Node ecosystem dependencies.
Application lifecycle security principle
The weakest link in an application lifecycle essentially defines the security of the entire application. Each step in the lifecycle can compromise the assumptions and integrity of all subsequent steps, so it is important to understand the whole picture at all times.
Tauri dependency maintenance and review
Tauri is a direct dependency on projects and maintains strict authorial control of commits, reviews, pull requests, and releases. The Tauri team maintains up-to-date dependencies and takes action to either update or fork and fix dependencies. Other projects may not be as well maintained or audited, so developers should consider the health of dependencies when integrating them.
Keep Tauri, compiler, and transpilers up to date
When releasing an application, it ships with Tauri as a bundle. Vulnerabilities affecting Tauri may impact application security. By updating Tauri to the latest version, critical vulnerabilities are patched and cannot be exploited. Developers should also keep the Rust compiler (rustc), Node.js transpilers (nodejs), and the entire development system up to date, as security issues are frequently resolved in updates.
Evaluate third-party dependencies for trustworthiness
It is the developer's responsibility to choose trustworthy third-party libraries or rewrite them in Rust. Using outdated libraries affected by known vulnerabilities or unmaintained libraries can jeopardize application security. Tools like npm audit and cargo audit should be used to automate vulnerability checking.
Supply chain attack mitigation tools
Recent trends in the Rust ecosystem include cargo-vet and cargo crev, which help reduce the likelihood of supply chain attacks. The cargo supply chain tool can be used to understand project dependencies and their origins.
GitHub Workflow provision for Tauri builds
Tauri provides a GitHub Workflow for building on multiple platforms to help with CI/CD.
Pin explicit versions in CI/CD third-party actions
When creating custom CI/CD systems that depend on third-party tooling, be cautious of actions whose versions have not been explicitly pinned.
Sign binaries for distribution platforms
Developers should sign their binaries for each platform they are shipping to. While this can be complicated and costly to set up, end users expect that the app is verifiably from the authentic developer.
Hardware token storage prevents signing key leaks
If cryptographic secrets are properly stored on hardware tokens, a compromised build system will not be able to leak involved signing keys, though it could potentially use them to sign malicious releases.
Rust reproducible builds limitations
Rust does not by default fully reliably produce reproducible builds. While it supports reproducible builds in theory, there are still bugs and it has recently broken on a release. The current state can be tracked in the Rust project's public bug tracker at https://github.com/rust-lang/rust/labels/A-reproducibility.
Frontend bundler reproducibility issues
Many common frontend bundlers do not produce reproducible output, meaning bundled assets may break reproducible builds. Developers cannot fully rely on reproducible builds by default and must fully trust their build systems.
Distribution threats from lost control of servers
If control is lost over the manifest server, build server, or binary hosting service, all bets are off for secure distribution. When building a custom distribution system, developers should consult a professional OPS architect.
CrabNebula as trusted Tauri distribution solution
CrabNebula offers a trusted distribution solution for Tauri apps as a partner. Their offering can be found at https://crabnebula.dev/cloud.
Webview assumed insecure by design
Tauri assumes the webview is insecure, which has led to implementation of several protections regarding webview access to system APIs in the context of loading untrusted userland content.
Content Security Policy for webview lockdown
Using Content Security Policy (CSP) will lockdown types of communication that the Webview can undertake, providing an additional layer of security against untrusted content.
Capabilities prevent untrusted content API access
Capabilities can prevent untrusted content or scripts from accessing the API within the Webview, restricting what functionality untrusted code can invoke.
Establish vulnerability reporting process
Developers should set up an easy and secure way to report vulnerabilities, similar to Tauri's security disclosure process, to allow the community to responsibly report security issues.
Development server security on untrusted networks
Tauri application frontend development servers expose frontend assets via an open port to the local system or network. This connection is often neither encrypted nor authenticated by default, exposing the frontend and assets to the local network. Attackers on the same network can push their own frontend code to development devices. Development should only occur on trusted networks, or the development server must use mutual authentication and encryption such as mTLS. The built-in Tauri development server does not support mutual authentication and transport encryption and should not be used on untrusted networks.
Development machine hardening recommendations
Recommended practices for hardening development systems include: never use administrative accounts for day-to-day tasks like coding; never use production secrets on development machines; prevent secrets from being checked into source code version control; use security hardware tokens or similar to reduce impact of compromised systems; keep the system up to date; keep installed applications to a minimum.
Source control authentication and authorization setup
To prevent unauthorized modification of source code, developers must understand and correctly set up access control for their source code version control system. Consider requiring all regular contributors to sign their commits to prevent malicious commits from being attributed to non-compromised contributors.
CI/CD system trust requirements
Organizations using CI/CD to manufacture binary artifacts must fully trust these remote and third-party owned systems, as they have access to source code, secrets, and can modify builds. Developers must either trust a reputable provider or host these systems on their own controlled hardware.
Permission structure TOML format
A permission is defined in TOML with fields: identifier (string, unique name), description (string), commands.allow (array of command names), permission.scope.allow (array of scope paths), and permission.scope.deny (array of scope paths to deny). The structure allows enabling/disabling commands and defining file system scopes.
Permission sets group related permissions
A permission set groups multiple permissions under a new identifier using the [[set]] header. Sets can combine scope-related permissions with command-related permissions, allowing reuse and simplification of configuration. Sets are defined with: identifier (string), description (string), and permissions (array of permission identifiers to include).
Permissions must be referenced in capabilities
To grant or deny a permission to an app's window or webview, the permission must be referenced in a capability file. Permissions alone do not grant access; they must be included in a capability definition.
Example extending plugin permissions in application
Applications can extend plugin permissions by creating a permission set that combines multiple plugin permissions. Example: a set with identifier 'allow-home-read-extended' combines fs:read-files, fs:scope-home, and fs:allow-mkdir to provide non-recursive read access and directory creation in the $HOME folder.
Permission identifier format and conventions
Permission identifiers use the format <name>:<command-name> or <name>:default. The 'name' is the plugin crate name without the 'tauri-plugin-' prefix, used for namespacing. The 'tauri-plugin-' prefix is automatically prepended at compile time. Identifiers are limited to ASCII lowercase alphabetic characters [a-z] with a maximum length of 116 characters, calculated as: MAX_LEN_PREFIX (64 - 13 = 51) + 1 (separator) + MAX_LEN_BASE (64).
Application permissions directory structure
Tauri application developers define permissions in src-tauri/permissions/ directory. Permission files use only TOML format (not JSON/JSON5). Capability files are located in src-tauri/capabilities/ and can use JSON, JSON5, or TOML format.
Runtime authority invocation flow
When a Tauri command is invoked from the webview, the runtime authority receives the invoke request, checks if the origin is allowed to use the requested command, verifies if the origin is part of capabilities, and if scopes are defined for the command and applicable, injects them into the invoke request before passing it to the proper Tauri command.
Runtime authority denies unauthorized command invocations
If the origin is not allowed to call the command, the runtime authority will deny the request and the Tauri command is never invoked.
Runtime authority holds permissions, capabilities, and scopes
The runtime authority is part of the Tauri Core. It holds all permissions, capabilities and scopes at runtime to enforce which window can access which command and passes scopes to commands.
Allow and deny scopes can be combined in permission sets
Deny and allow scopes can be merged into a single permission set, which allows specifying complex permission combinations that restrict access to certain folders while allowing access to parent directories.
Scope types are serde serializable and plugin-specific
The scope type needs to be of any serde serializable type. These types are plugin-specific in general. For scoped commands implemented in a Tauri application, the scope type needs to be defined in the application and then enforced in the command implementation.
Deny scopes can be merged into named sets
Deny scopes can be merged into a set using the [[set]] configuration, which reduces duplicate configuration and makes it more understandable for anyone looking into the application configuration.