Documentation Technique : Migration n8n v2.0 – Standards de Sécurité

🆕 Mise à jour 2026. n8n continue d’évoluer après la version 2.0 ; les concepts présentés ici restent valables, mais vérifiez les notes de version pour les détails d’interface les plus récents.

Contexte Architectural

Avec la version 2.0, n8n adopte une architecture « Secure by Default ». L’objectif est de prévenir les failles d’exécution de code à distance (RCE) et l’exfiltration de données sur les instances exposées publiquement. Par défaut, l’application fonctionne désormais en mode « bac à sable » restreint.

Cette documentation détaille les deux changements majeurs impactant les environnements self-hosted et les procédures de remédiation via Docker.

1. Restriction d’accès aux fichiers (N8N_RESTRICT_FILE_ACCESS_TO)

Le Changement

• Avant v2.0 : n8n pouvait lire et écrire n’importe quel fichier accessible par l’utilisateur système du conteneur (généralement root ou node), incluant / si les permissions le permettaient.
• Depuis v2.0 : L’accès est strictement confiné au répertoire de données de n8n (/home/node/.n8n). Toute tentative de lecture/écriture hors de ce périmètre via les nœuds Read/Write Binary File échoue.

L’Impact

Les workflows interagissant avec des fichiers locaux montés via Docker (ex: /local-files, /tmp) ou des volumes externes cesseront de fonctionner avec une erreur de permission (« Forbidden path »).

La Solution

Pour restaurer le comportement permissif de la v1 ou définir des chemins spécifiques, vous devez surcharger la variable d’environnement N8N_RESTRICT_FILE_ACCESS_TO.

• Option A (Sécurisée – Recommandée) : Lister explicitement les chemins autorisés.
• Option B (Permissive – Legacy) : Désactiver totalement la restriction.

2. Désactivation des nœuds système (NODES_EXCLUDE)

Le Changement

• Avant v2.0 : Tous les nœuds étaient activés par défaut.
• Depuis v2.0 : Les nœuds considérés comme critiques pour la sécurité sont désactivés par défaut. Il s’agit de :
  1. Execute Command (Risque : RCE totale).
  2. Local File Trigger (Risque : Accès non sollicité au système de fichiers).

L’Impact

Les workflows contenant ces nœuds afficheront une erreur au démarrage ou à l’exécution, indiquant que le type de nœud n’est pas reconnu ou est désactivé. Ils disparaissent également du panneau de sélection des nœuds.

La Solution

Il faut vider la liste d’exclusion définie par la variable NODES_EXCLUDE. La valeur par défaut interne est ["n8n-nodes-base.executeCommand", "n8n-nodes-base.localFileTrigger"]. Pour les réactiver, il faut passer un tableau JSON vide.

Implémentation Technique (Docker Compose)

Voici la configuration à intégrer dans votre fichier docker-compose.yml pour lever ces deux restrictions simultanément.

YAML

services:
  n8n:
    environment:
      # ... other variables ...

      # -------------------------------------------------------
      # SECURITY OVERRIDES FOR N8N V2.0
      # -------------------------------------------------------

      # 1. File Access
      # Set to empty string to allow access to root (v1 behavior)
      # Or specify paths: "/data/files:/tmp"
      - N8N_RESTRICT_FILE_ACCESS_TO=

      # 2. Node Visibility
      # Set to empty JSON array string to enable all nodes
      # Re-enables: Execute Command, Local File Trigger
      - NODES_EXCLUDE="[]"

Synthèse des variables