new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Tauri · all subjects

security model & trust

15 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

What capabilities protect against

Permissions and capabilities minimize the impact of security breaches on the frontend, prevent or mitigate accidental leakage of local system interfaces and data, and prevent or mitigate privilege escalation from frontend to backend or system.

What capabilities do not protect against

Capabilities do not protect against: malicious or unsafe Rust code, overly permissive scopes and configurations, inaccurate scope checks in command implementations, intentional bypasses from Rust code, anything written in the app's Rust core, zero-day or unpatched one-day exploits in the system WebView, supply chain attacks, or compromised developer systems.

Security boundaries depend on window labels

Security boundaries depend on window labels, not window titles. Window creation capabilities should only be available to windows with higher privileges.

Dependency evaluation tools and best practices

Use automated tools like npm Audit and cargo Audit to identify known vulnerabilities. Recent Rust ecosystem tools like cargo-vet and cargo-crev help reduce supply chain attack risk. Use cargo supply chain to understand your dependencies. Best practice is to use hash revisions for critical git dependencies; second choice is named tags. This applies to both Rust and Node ecosystems.

Development server security risk

Frontend development servers for Tauri applications typically lack encryption and authentication by default, exposing frontend assets over open ports to the local system and network. This allows attackers on the same network to push malicious frontend code to development devices. Development should only occur on trusted networks, or the development server must use mutual authentication and encryption (like mTLS).

Tauri built-in development server limitations

The built-in Tauri development server does not currently support mutual authentication and transport encryption, so it should not be used on untrusted networks.

Development machine hardening practices

Do not use administrator accounts for daily tasks like coding. Do not use production secrets on development machines. Do not commit secrets to source control. Use security hardware tokens to mitigate impact of compromised systems. Keep systems updated and minimize installed applications.

Source control security best practices

Understand and correctly configure access controls in version management systems to prevent unauthorized changes. Consider requiring commit signing from all contributors to prevent malicious commits from being misattributed to legitimate contributors.

Webview security assumption

Tauri assumes webviews are not secure. To protect against untrusted user-land content being loaded in the webview, Tauri implements protections limiting webview access to system APIs.

Content Security Policy in Tauri

Content Security Policy (CSP) is used in Tauri to block communication types that the webview can execute.

Keep Tauri and compiler toolchain updated

When shipping a Tauri-bundled application, vulnerabilities in Tauri affect application security. Keep Tauri to the latest version to ensure critical vulnerabilities are patched. Also keep rustc compiler and nodejs transpiler up to date as security issues are frequently resolved in these tools.

Core application lifecycle security principle

The weakest link in the application lifecycle determines the overall security. Each stage of processing becomes the premise for all subsequent stages, so maintaining integrity across all stages is critical.

Application lifecycle threat stages

Tauri applications face threats across five stages: Upstream (dependency management), Development (development environment security), Building (CI/CD and binary generation), Distribution (update delivery), and Runtime (webview execution).

Message passing safety model: Core can reject malicious requests

Message passing is a safer technique than shared memory or direct function access because the recipient is free to reject or discard requests as it sees fit. For example, if the Tauri Core process determines a request to be malicious, it simply discards the request and never executes the corresponding function.

Commands use message passing, not real FFI, avoiding FFI security pitfalls

Commands still use message passing under the hood and do not share the same security pitfalls as real FFI interfaces do.

Give your agent this brain