Errores peligrosos en Tauri: 5 configuraciones inseguras que vienen activadas de forma predeterminada

Un modelo de seguridad es tan sólido como lo sean sus valores predeterminados. Tauri se ha posicionado como la alternativa a Electron para crear aplicaciones de escritorio pensada para quienes priorizan la seguridad. Su arquitectura divide la confianza entre un backend de Rust ("Core") y un frontend web ("Renderer"), con una capa IPC que media el acceso.

En teoría, esto representa una mejora importante frente al antiguo modelo de Electron, en el que Node.js se ejecuta en el propio proceso de renderizado (aunque hoy en día el renderer de Electron ya incluye de forma predeterminada el aislamiento de contexto y el sandbox, por lo que solo el proceso principal tiene acceso directo a Node.js). Tauri también puede ser más ligero que Electron y tiene la ventaja de admitir varios frameworks de backend que puedes integrar directamente en Tauri para obtener una aplicación de escritorio funcional.

Tras analizar las opciones de configuración de Tauri, identificamos cinco errores comunes, algunos de los cuales vienen activados de forma predeterminada o aparecen en ejemplos oficiales, que pueden desmantelar silenciosamente las garantías de seguridad del framework.

1. Comodín en el protocolo de assets: cuando "/**/*" significa todo el disco

El protocolo de assets de Tauri permite que tu frontend cargue archivos locales. Es útil para mostrar imágenes, cargar datos locales o servir contenido estático. El problema surge cuando el alcance se configura con un comodín como /**/*:

// src-tauri/tauri.conf.json
{
  "security": {
    "assetProtocol": {
      "enable": true,
      "scope": ["/**/*"]
    }
  }
}

Con esta configuración, cualquier JavaScript que se ejecute en cualquier ventana del renderer puede llamar a fetch("asset://localhost/etc/passwd") y leer cualquier archivo al que tenga acceso el proceso de la aplicación. No se requiere ninguna acción del usuario, cuadro de confirmación ni verificación de permisos adicional.

La amenaza no se limita a tu propio código. Una sola vulnerabilidad XSS, una dependencia de npm comprometida o incluso un script malicioso inyectado a través de un webview obtendrían acceso de lectura al sistema de archivos local. Esto convierte, en la práctica, al renderer en una herramienta para exfiltrar archivos locales.

Qué hacer: Limita el alcance del protocolo de assets a los directorios específicos que realmente necesita tu aplicación. Nunca uses /**/* en producción. Si no necesitas el protocolo de assets, desactívalo por completo.

2. Un alcance de comandos vacío permite todo

El sistema de permisos de Tauri permite que los desarrolladores definan alcances de comandos para restringir las entradas que aceptan. Sin embargo, cuando no hay una ACL configurada para un comando, el código devuelve un CommandScope vacío en lugar de denegar el acceso.

Esto va contra la intuición. Un desarrollador podría esperar razonablemente que, de forma predeterminada, un comando sin configurar deniegue todas las operaciones (un enfoque de «denegar de forma predeterminada»). En cambio, el método matches() de un alcance vacío devuelve true para todas las entradas.

// Developer expects this to be restrictive, but it allows everything
fn handle_command(scope: CommandScope<MyArgs>) {
    if scope.matches(&user_input) {
        // This always passes when scope is empty
        execute(user_input);
    }
}

Para implementar realmente el comportamiento de denegar de forma predeterminada, los desarrolladores deben verificar manualmente scope.allows().is_empty() y gestionar ese caso por su cuenta.

En combinación con el error peligroso n.º 1, esto significa que un desarrollador que no haya configurado explícitamente los alcances de sus comandos podría estar exponiendo, sin saberlo, un acceso amplio a cualquier script del renderer.

Qué hacer: Define siempre alcances permitidos explícitos para cada comando que exponga tu aplicación. Considera los alcances vacíos como un error de seguridad. Puedes crear una función auxiliar para las verificaciones de alcance que aplique la denegación de forma predeterminada.

3. Contaminación de prototipos mediante objetos sin congelar

De forma predeterminada, Tauri no congela Object.prototype en el contexto del renderer. La opción freezePrototype existe, pero su valor predeterminado es false.

Esto importa porque el mecanismo IPC de Tauri funciona a través de JavaScript. Si un atacante logra contaminar los prototipos (una clase de ataque bien documentada en JavaScript), podría secuestrar llamadas IPC al modificar los prototipos que utiliza el puente de Tauri.

// tauri.conf.json — not enabled by default
{
  "app": {
    "security": {
      "freezePrototype": true
    }
  }
}

La contaminación de prototipos ya es un riesgo conocido en las aplicaciones web, pero en una aplicación de escritorio con acceso IPC al sistema local, el impacto aumenta considerablemente. Un prototipo contaminado podría redirigir llamadas IPC, modificar argumentos de comandos o interceptar respuestas.

Qué hacer: Configura freezePrototype: true en tu configuración de Tauri. Es un cambio de una sola línea con un impacto mínimo en el código legítimo.

4. Capacidades de ventana con comodines

El sistema de capacidades de Tauri permite asignar permisos a ventanas específicas. Sin embargo, usar un comodín como identificador de ventana otorga la capacidad a todas las ventanas de la aplicación:

{
  "identifier": "my-capability",
  "windows": ["*"],
  "permissions": ["fs:allow-read-text-file"]
}

Este patrón coincide con todas las ventanas, incluidas las que se crean dinámicamente, las nuevas ventanas del navegador o las que podría abrir un script malicioso. Si una ventana se ve comprometida, el atacante no necesita escapar a otras ventanas porque todas ya comparten los mismos permisos.

Esto se demostró en la práctica con una aplicación basada en Tauri que otorgaba permisos demasiado amplios entre ventanas, debilitando el modelo de contención que las capacidades deberían ofrecer.

Qué hacer: Especifica siempre los identificadores de ventana de forma explícita. Revisa la configuración de tus capacidades para asegurarte de que los permisos se limiten al conjunto mínimo de ventanas que realmente los necesitan.

5. Navegación permisiva de forma predeterminada

El comportamiento de navegación predeterminado de Tauri permite que el webview navegue a cualquier URL. No hay una lista de permitidos integrada. Los desarrolladores deben implementar sus propias restricciones explícitas de navegación.

Por sí solo, esto representa un riesgo moderado: un ataque XSS podría redirigir el webview a un sitio de phishing o iniciar descargas. Pero, al combinarse con la capacidad de ventana con comodín (error peligroso n.º 4) y restricciones débiles del origen IPC, se convierte en un vector de escalamiento de privilegios.

Así funciona la cadena de ataque: un atacante dirige una ventana con privilegios a un origen que controla y luego invoca comandos IPC de Tauri desde ese contexto. Si la capacidad de la ventana usa "*", el origen del atacante hereda todos los permisos asignados a esa capacidad.

Qué hacer: Implementa un manejador de navegación que restrinja los orígenes permitidos. Permite navegar únicamente a los dominios que tu aplicación necesita cargar de forma explícita.

El efecto combinado

Cada uno de estos problemas está documentado por separado, y algunos incluso tienen CVE asociadas (como CVE-2024-35222 por la omisión del control de acceso IPC y CVE-2022-39215 por la omisión del alcance a través de enlaces simbólicos). Pero el verdadero riesgo está en cómo se combinan.

Una sola vulnerabilidad XSS en una aplicación Tauri con la configuración predeterminada podría encadenar estos problemas: prototipos sin congelar para secuestrar IPC, alcances con comodines para acceder a cualquier comando, comodines en el protocolo de assets para leer el sistema de archivos y navegación permisiva para exfiltrar datos a un origen controlado por el atacante.

El modelo de seguridad de Tauri es similar al de Electron en cuanto a su arquitectura. Pero la arquitectura por sí sola no permite crear software seguro: también importan los valores predeterminados. Y ahora mismo, varios de los valores predeterminados de Tauri van en contra de las garantías de seguridad que el framework busca ofrecer.

Acciones recomendadas

1. Audita tus archivos tauri.conf.json y de capacidades para detectar cada uno de los errores peligrosos mencionados arriba

2. Configura freezePrototype: true

3. Reemplaza todos los alcances con comodines (/**/*, *) por rutas e identificadores de ventana explícitos

4. Implementa una lista de dominios permitidos para la navegación

5. Agrega alcances explícitos de permisos permitidos o denegados a cada comando expuesto

6. Usa Snyk para analizar las dependencias de Rust y JavaScript de tu aplicación Tauri en busca de vulnerabilidades conocidas

¿Tus aplicaciones de escritorio están protegidas contra configuraciones incorrectas encadenadas que pueden convertir una sola falla en el compromiso total del sistema? Descarga el whitepaper La crisis de seguridad de la IA en tu entorno de Python para descubrir cómo los equipos modernos protegen el desarrollo impulsado por IA en distintos lenguajes y frameworks.