understanding-tauri-lifecycle-security

What this skill does

# Tauri Application Lifecycle Security

Security in Tauri applications depends on systematic protection across all lifecycle stages. The weakest link in your application lifecycle essentially defines your security posture.

## Core Security Principle

Tauri implements a two-tier security model:
- **Rust Core**: Full system access
- **WebView Frontend**: Access only through controlled IPC layer

Any code executed in the WebView has only access to exposed system resources via the well-defined IPC layer.

---

## Development Phase Threats

### Upstream Dependency Risks

Third-party dependencies may lack the strict oversight that Tauri maintains.

**Mitigation Strategies:**

```bash
# Scan Rust dependencies for vulnerabilities
cargo audit

# Scan npm dependencies
npm audit

# Advanced supply chain analysis
cargo vet
cargo crev
cargo supply-chain
```

**Best Practices:**
- Keep Tauri, `rustc`, and `nodejs` current to patch vulnerabilities
- Evaluate trustworthiness of third-party libraries before integration
- Prefer consuming critical dependencies via git hash revisions rather than version ranges

```toml
# Cargo.toml - Pin to specific commit hash
[dependencies]
critical-lib = { git = "https://github.com/org/critical-lib", rev = "abc123def456" }
```

### Development Server Exposure

Development servers typically run unencrypted and unauthenticated on local networks, allowing attackers to push malicious frontend code to development devices.

**Threat Scenario:**
```
Attacker on same network -> Intercepts dev server traffic -> Injects malicious frontend code
```

**Mitigation:**
- Develop only on trusted networks
- Implement mutual TLS (mTLS) authentication when necessary
- Note: Tauri's built-in dev server lacks mutual authentication features

### Machine Hardening

| Practice | Purpose |
|----------|---------|
| Avoid admin accounts for coding | Limit blast radius of compromise |
| Block secrets from version control | Prevent credential leaks |
| Use hardware security tokens | Minimize compromise impact |
| Minimize installed applications | Reduce attack surface |

### Source Control Security

**Required Protections:**
- Implement proper access controls in version control systems
- Require contributor commit signing to prevent unauthorized attribution
- Use established hardening guidelines for authentication workflows

```bash
# Enable commit signing
git config --global commit.gpgsign true
git config --global user.signingkey YOUR_KEY_ID
```

---

## Build Phase Threats

### Build System Trust

CI/CD systems access source code, secrets, and can modify builds without local verification.

**Threat Vectors:**
1. Compromised CI/CD provider
2. Malicious build scripts
3. Unauthorized secret access
4. Build artifact tampering

**Mitigation Options:**
- Trust reputable third-party providers (GitHub Actions, GitLab CI)
- Host and control your own infrastructure for sensitive applications

### Binary Signing

Applications must be cryptographically signed for their target platform.

**Platform Requirements:**

| Platform | Signing Requirement |
|----------|---------------------|
| macOS | Apple Developer Certificate + Notarization |
| Windows | Code Signing Certificate (EV recommended) |
| Linux | GPG signing for packages |

**Key Protection:**
```bash
# Use hardware tokens for signing credentials
# Prevents compromised build systems from leaking keys

# Example: Using YubiKey for code signing
pkcs11-tool --module /usr/lib/opensc-pkcs11.so --sign
```

Hardware tokens prevent key exfiltration but cannot prevent key misuse on a compromised system.

### Reproducible Builds Challenge

Rust is not fully reliable at producing reproducible builds despite theoretical support. Frontend bundlers similarly struggle with reproducible output.

**Implications:**
- Cannot entirely eliminate reliance on build system trust
- Implement multiple verification layers
- Consider build provenance attestation

---

## Distribution Threats

Loss of control over manifest servers, build servers, or binary hosting creates critical vulnerability points.

### Attack Vectors

```
Manifest Server Compromise -> Malicious update metadata -> Users download tampered binaries
Build Server Compromise -> Injected malware at build time -> Signed malicious releases
Binary Host Compromise -> Replaced binaries -> Users download malicious versions
```

### Mitigation Strategies

1. **Secure Update Channels**
   - Use HTTPS for all update communications
   - Implement certificate pinning where possible
   - Verify update signatures client-side

2. **Binary Integrity**
   - Publish checksums alongside releases
   - Use signed manifests for updates
   - Consider transparency logs

3. **Infrastructure Security**
   - Multi-factor authentication for all distribution systems
   - Audit logging for binary access
   - Separate credentials for different environments

---

## Runtime Threats

### WebView Security Model

Tauri assumes webview components are inherently insecure and implements multiple protection layers.

**Defense Layers:**

```
                    +------------------+
                    |   Untrusted      |
                    |   Frontend Code  |
                    +--------+---------+
                             |
                    +--------v---------+
                    |       CSP        |  <- Restricts communication types
                    +--------+---------+
                             |
                    +--------v---------+
                    |   Capabilities   |  <- Controls API access
                    +--------+---------+
                             |
                    +--------v---------+
                    |   Permissions    |  <- Fine-grained command control
                    +--------+---------+
                             |
                    +--------v---------+
                    |      Scopes      |  <- Resource-level restrictions
                    +--------+---------+
                             |
                    +--------v---------+
                    |   Rust Backend   |  <- Trusted system access
                    +------------------+
```

### Content Security Policy (CSP)

CSP restricts webview communication types to prevent XSS and injection attacks.

**Configuration in `tauri.conf.json`:**

```json
{
  "app": {
    "security": {
      "csp": "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'"
    }
  }
}
```

**CSP Best Practices:**
- Start with restrictive policy, relax only as needed
- Avoid `'unsafe-eval'` and `'unsafe-inline'` for scripts
- Use nonces or hashes for inline scripts when required

### Capabilities Configuration

Define which permissions are granted to specific windows.

**Example: `src-tauri/capabilities/main.json`**

```json
{
  "$schema": "../gen/schemas/desktop-schema.json",
  "identifier": "main-capability",
  "description": "Capability for the main window",
  "windows": ["main"],
  "permissions": [
    "core:path:default",
    "core:window:allow-set-title",
    "fs:read-files"
  ]
}
```

**Security Notes:**
- Windows in multiple capabilities merge security boundaries
- Security boundaries depend on window labels, not titles
- Capabilities protect against frontend compromise and privilege escalation

### Permission Scopes

Control resource access at a granular level.

**Example: File System Scope**

```toml
# src-tauri/permissions/fs-restricted.toml
[[permission]]
identifier = "fs-home-restricted"
description = "Allow home directory access except secrets"
commands.allow = ["read_file", "write_file"]

[[scope.allow]]
path = "$HOME/*"

[[scope.deny]]
path = "$HOME/.ssh/*"

[[scope.deny]]
path = "$HOME/.gnupg/*"

[[scope.deny]]
path = "$HOME/.aws/*"
```

### Prototype Freezing

Prevent JavaScript prototype pollution attacks.

```json
{
  "app": {
    "security": {
      "freezePrototype": true
    }
  }
}
```

### Remote API Access Control

Control which external URLs can access Tauri commands.

```jso