Seguridad y Permisos

Tauri v2 implementa un modelo de seguridad granular. Nada esta habilitado por defecto — debes otorgar permisos explicitamente.

Modelo de seguridad

Limite de confianza

El codigo en el Webview no es confiable. Solo tiene acceso a lo que el Core expone via IPC. Esto significa:

• Ningun comando esta disponible sin permiso explicito
• Cada ventana puede tener permisos diferentes
• Los plugins no funcionan hasta que habilites sus permisos

Capas de proteccion

Webview (no confiable)
    ↓ IPC
Capabilities (que puede hacer cada ventana)
    ↓
Permissions (que comandos estan habilitados)
    ↓
Scopes (restricciones por recurso)
    ↓
Core Rust (confiable)

Capabilities

Son archivos JSON en src-tauri/capabilities/ que definen que puede hacer cada ventana:

{
  "identifier": "default",
  "description": "Permisos de la ventana principal",
  "windows": ["main"],
  "permissions": [
    "core:default",
    "fs:allow-read-text-file",
    "dialog:allow-open",
    "store:allow-get",
    "store:allow-set"
  ]
}

Multiples ventanas con permisos diferentes

// capabilities/main.json
{
  "identifier": "main-window",
  "windows": ["main"],
  "permissions": ["core:default", "fs:default", "dialog:default"]
}

// capabilities/settings.json
{
  "identifier": "settings-window",
  "windows": ["settings"],
  "permissions": ["core:default", "store:allow-get", "store:allow-set"]
}

La ventana settings no puede acceder al filesystem ni a dialogos.

Por plataforma

{
  "identifier": "desktop-only",
  "windows": ["main"],
  "platforms": ["linux", "macOS", "windows"],
  "permissions": ["shell:allow-open"]
}

Permisos

Cada plugin define permisos con formato plugin:accion:

Formato	Ejemplo	Descripcion
plugin:allow-comando	fs:allow-read-text-file	Habilita un comando
plugin:deny-comando	fs:deny-write-file	Bloquea un comando
plugin:default	fs:default	Permisos por defecto del plugin

Los deny siempre ganan sobre los allow.

Scopes

Restringen que recursos puede acceder un permiso. Ejemplo con filesystem:

{
  "identifier": "default",
  "windows": ["main"],
  "permissions": [
    {
      "identifier": "fs:allow-read-text-file",
      "allow": [
        { "path": "$APPDATA/**" },
        { "path": "$HOME/Documents/**" }
      ],
      "deny": [
        { "path": "$HOME/Documents/privado/**" }
      ]
    }
  ]
}

Variables de scope disponibles:

Variable	Ruta
$APPDATA	Directorio de datos de la app
$HOME	Home del usuario
$DESKTOP	Escritorio
$DOWNLOAD	Descargas
$DOCUMENT	Documentos
$TEMP	Directorio temporal

Content Security Policy (CSP)

Tauri inyecta CSP automaticamente para prevenir XSS. Puedes personalizarlo en tauri.conf.json:

{
  "app": {
    "security": {
      "csp": "default-src 'self'; img-src 'self' https://cdn.ejemplo.com; style-src 'self' 'unsafe-inline'"
    }
  }
}

En desarrollo, el CSP es mas permisivo para facilitar hot reload.

Permisos para comandos propios

Tus comandos tambien necesitan permisos. Crea src-tauri/capabilities/default.json:

{
  "identifier": "default",
  "windows": ["main"],
  "permissions": [
    "core:default",
    "my-app:allow-greet",
    "my-app:allow-login"
  ]
}

Mejores practicas

• Minimo privilegio: solo habilita los permisos que necesitas
• Scopes restrictivos: limita acceso a filesystem a directorios especificos
• Ventanas separadas: distintas capabilities por ventana
• deny sobre allow: bloquea explicitamente lo que no debe ser accesible
• CSP estricto: no uses unsafe-eval en produccion
• Revisa dependencias: las dependencias Rust tambien pueden tener vulnerabilidades

Resumen

• Nada esta habilitado por defecto — permisos explicitos obligatorios
• Capabilities definen permisos por ventana en archivos JSON
• Scopes restringen que recursos puede acceder un permiso
• deny siempre gana sobre allow
• CSP inyectado automaticamente contra XSS
• Principio de minimo privilegio: solo habilita lo necesario

---

← Sistema de Plugins | Indice | Siguiente: Personalizacion de Ventanas →