Tauri : 5 erreurs de configuration courantes qui compromettent la sécurité par défaut

Un modèle de sécurité n’est jamais plus solide que ses paramètres par défaut. Tauri s’est imposé comme une alternative à Electron privilégiant la sécurité pour créer des applications de bureau. Son architecture répartit la confiance entre un backend Rust (« Core ») et un frontend web (« Renderer »), avec une couche IPC qui contrôle les accès.

Sur le papier, c’est une nette amélioration par rapport à l’ancien modèle d’Electron, où Node.js s’exécute dans le processus de rendu lui-même (même si, aujourd’hui, l’isolation du contexte et le sandboxing sont déjà activés par défaut dans le processus de rendu d’Electron : seul le processus principal a donc un accès direct à Node.js). Tauri peut aussi être plus léger qu’Electron et présente l’avantage de prendre en charge plusieurs frameworks backend que vous pouvez simplement intégrer pour obtenir une application de bureau fonctionnelle.

Après avoir étudié les options de configuration de Tauri, nous avons relevé cinq erreurs courantes, dont certaines correspondent aux paramètres par défaut ou figurent dans les exemples officiels, qui peuvent discrètement démanteler les garanties de sécurité du framework.

1. Joker dans le protocole des ressources : quand « /**/* » désigne tout le disque

Le protocole des ressources de Tauri permet à votre frontend de charger des fichiers locaux. Il est utile pour afficher des images, charger des données locales ou servir du contenu statique. Le problème survient lorsque le périmètre est configuré avec un joker tel que /**/* :

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

Avec cette configuration, n’importe quel code JavaScript exécuté dans n’importe quelle fenêtre de rendu peut appeler fetch("asset://localhost/etc/passwd") et lire tous les fichiers accessibles au processus de l’application. Aucun geste de l’utilisateur, aucune boîte de dialogue de confirmation ni vérification d’autorisation supplémentaire ne sont nécessaires.

La menace ne se limite pas à votre propre code. Une seule vulnérabilité XSS, une dépendance npm compromise ou même un script malveillant injecté dans une webview suffirait à donner accès en lecture au système de fichiers local. Le processus de rendu devient alors, de fait, un outil d’exfiltration de fichiers locaux.

Que faire : Limitez le protocole des ressources aux répertoires dont votre application a réellement besoin. N’utilisez jamais /**/* en production. Si vous n’avez pas besoin de ce protocole, désactivez-le complètement.

2. Un périmètre de commandes vide autorise tout

Le système d’autorisations de Tauri permet aux développeurs de définir des périmètres de commandes afin de limiter les entrées acceptées. Toutefois, lorsqu’aucune ACL n’est configurée pour une commande, le code renvoie un CommandScope vide au lieu de refuser l’accès.

C’est contre-intuitif. Un développeur pourrait raisonnablement s’attendre à ce qu’une commande non configurée refuse toutes les opérations par défaut (une approche de « refus par défaut »). Pourtant, la méthode matches() renvoie true pour toutes les entrées lorsque le périmètre est vide.

// 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);
    }
}

Pour appliquer réellement le refus par défaut, les développeurs doivent vérifier manuellement scope.allows().is_empty() et gérer eux-mêmes ce cas.

Combiné au piège n° 1, cela signifie qu’un développeur qui n’a pas explicitement configuré de périmètres pour ses commandes risque d’exposer sans le savoir un accès étendu à n’importe quel script exécuté dans le processus de rendu.

Que faire : Définissez toujours des périmètres d’autorisation explicites pour chaque commande exposée par votre application. Considérez les périmètres vides comme un problème de sécurité. Envisagez d’encapsuler vos vérifications de périmètre dans une fonction auxiliaire qui applique le refus par défaut.

3. Pollution de prototypes due à des objets non gelés

Par défaut, Tauri ne gèle pas Object.prototype dans le contexte de rendu. L’option freezePrototype existe, mais sa valeur par défaut est false.

C’est important, car le mécanisme IPC de Tauri s’exécute via JavaScript. Si un attaquant parvient à provoquer une pollution de prototypes (une catégorie d’attaque bien connue en JavaScript), il peut potentiellement détourner des appels IPC en modifiant les prototypes utilisés par le pont Tauri.

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

La pollution de prototypes est déjà un risque connu dans les applications web. Mais dans une application de bureau disposant d’un accès IPC au système local, ses conséquences sont bien plus graves. Un prototype compromis pourrait rediriger des appels IPC, modifier les arguments des commandes ou intercepter les réponses.

Que faire : Définissez freezePrototype: true dans la configuration de Tauri. Ce changement d’une seule ligne a un impact minime sur le code légitime.

4. Capacités attribuées à toutes les fenêtres

Le système de capacités de Tauri permet aux développeurs d’attribuer des autorisations à des fenêtres spécifiques. Mais l’utilisation d’un joker comme identifiant de fenêtre accorde la capacité à toutes les fenêtres de l’application :

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

Ce modèle correspond à toutes les fenêtres, y compris celles créées dynamiquement, les nouvelles fenêtres de navigateur ou celles qu’un script malveillant pourrait ouvrir. Si une fenêtre est compromise, l’attaquant n’a pas besoin de s’échapper vers d’autres fenêtres : elles partagent déjà les mêmes autorisations.

Ce problème a été mis en évidence dans une application basée sur Tauri qui accordait des autorisations trop étendues à plusieurs fenêtres, affaiblissant ainsi le modèle de cloisonnement que les capacités sont censées garantir.

Que faire : Spécifiez toujours explicitement les identifiants des fenêtres. Vérifiez votre configuration des capacités pour que les autorisations soient limitées au nombre minimal de fenêtres qui en ont réellement besoin.

5. Navigation autorisée par défaut

Par défaut, Tauri permet à la webview de naviguer vers n’importe quelle URL. Aucune liste d’autorisation n’est intégrée. Les développeurs doivent définir eux-mêmes des restrictions explicites pour la navigation.

Pris isolément, le risque est modéré : une attaque XSS pourrait rediriger la webview vers un site d’hameçonnage ou déclencher des téléchargements. Mais combiné aux capacités de fenêtre avec joker (piège n° 4) et à de faibles restrictions sur l’origine IPC, ce problème devient un vecteur d’élévation de privilèges.

Voici le déroulement de l’attaque : l’attaquant redirige une fenêtre privilégiée vers une origine qu’il contrôle, puis appelle des commandes IPC de Tauri depuis ce contexte. Si la capacité de la fenêtre utilise "*", l’origine de l’attaquant hérite de toutes les autorisations associées à cette capacité.

Que faire : Implémentez un gestionnaire de navigation qui limite les origines autorisées. N’autorisez la navigation que vers les domaines que votre application doit explicitement charger.

L’effet cumulatif

Chacun de ces problèmes est documenté individuellement et certains ont même des CVE correspondantes (notamment CVE-2024-35222 pour le contournement du contrôle d’accès IPC et CVE-2022-39215 pour le contournement du périmètre via des liens symboliques). Mais le véritable risque vient de leur cumul.

Une seule vulnérabilité XSS dans une application Tauri utilisant la configuration par défaut pourrait enchaîner plusieurs attaques : des prototypes non gelés pour détourner IPC, des périmètres avec joker pour accéder à toutes les commandes, des jokers dans le protocole des ressources pour lire le système de fichiers et une navigation permissive pour exfiltrer des données vers une origine contrôlée par l’attaquant.

L’architecture du modèle de sécurité de Tauri ressemble à celle d’Electron. Mais une architecture à elle seule ne suffit pas à livrer un logiciel sécurisé. Ce sont les paramètres par défaut qui comptent, et plusieurs d’entre eux compromettent actuellement les garanties de sécurité que le framework est censé fournir.

Mesures recommandées

1. Vérifiez vos fichiers tauri.conf.json et vos fichiers de capacités à la lumière de chacun des pièges ci-dessus

2. Définissez freezePrototype: true

3. Remplacez tous les périmètres avec joker (/**/*, *) par des chemins et des identifiants de fenêtre explicites

4. Implémentez une liste d’autorisation pour la navigation

5. Ajoutez des périmètres d’autorisation ou de refus explicites à chaque commande exposée

6. Utilisez Snyk pour analyser les dépendances Rust et JavaScript de votre application Tauri à la recherche de vulnérabilités connues

Vos applications de bureau sont-elles protégées contre les erreurs de configuration qui, en chaîne, peuvent transformer une simple faille en compromission complète du système ? Téléchargez le livre blanc La crise de la sécurité de l’IA dans votre environnement Python pour découvrir comment les équipes modernes sécurisent le développement fondé sur l’IA, dans différents langages et frameworks.