Durcissement de la sécurité : 2FA, protection SSRF, blocage de nodes, désactivation de la Public API

Quiconque exploite une instance n8n auto-hébergée assume entièrement seul la responsabilité de sa sécurisation, car n8n Cloud prend automatiquement en charge une partie de ces mesures de protection, alors qu'un serveur géré soi-même ne le fait pas de lui-même. Rien que dans la section configuration de la sécurité de la documentation officielle de n8n, on trouve plus d'une douzaine de chapitres distincts, de l'authentification à deux facteurs à la Public API en passant par la protection SSRF, qui n'avaient jusqu'ici jamais été rassemblés sous cette forme en allemand. Les quatre leviers les plus importants pour l'exploitation courante sont : rendre la 2FA disponible et l'exiger, activer la protection SSRF, verrouiller les nodes à risque via NODES_EXCLUDE et désactiver la Public API si personne n'en a besoin. Mise à jour : juillet 2026.

Activer l'authentification à deux facteurs

n8n active la fonction 2FA à l'échelle de l'instance via la variable d'environnement N8N_MFA_ENABLED, dont la valeur par défaut est true. Les utilisateurs individuels peuvent ainsi configurer eux-mêmes l'authentification à deux facteurs dans leurs paramètres de compte personnels, mais un interrupteur central obligeant tous les comptes simultanément n'est pas décrit dans la documentation de base. Important en pratique : une fois qu'un utilisateur a activé la 2FA, n8n ignore, selon la documentation, une désactivation ultérieure via la variable d'environnement, la protection ne peut donc pas être annulée par inadvertance via un changement de configuration.

• N8N_MFA_ENABLED : booléen, valeur par défaut true, détermine si la 2FA est du tout disponible dans le compte utilisateur.
• Pas de retour en arrière : une fois la 2FA activée par un utilisateur, elle reste en place même si la variable d'environnement est ensuite définie sur false.
• Obligation organisationnelle : comme n8n n'impose pas l'activation de manière centralisée, vous devez obliger votre équipe en interne à réellement configurer la 2FA.

Protection SSRF contre les accès aux systèmes internes

Server-Side Request Forgery signifie qu'un node de workflow, par exemple le node HTTP Request, est détourné pour envoyer des requêtes vers des ressources réseau internes, des endpoints de métadonnées cloud ou des services localhost qui ne devraient normalement pas être accessibles depuis l'extérieur. n8n propose pour cela son propre mécanisme de protection depuis la version 2.12.0, activable via N8N_SSRF_PROTECTION_ENABLED=true. Lorsque la protection est active, n8n vérifie les requêtes HTTP sortantes issues des nodes contrôlés par l'utilisateur par rapport à des listes d'autorisation et de blocage configurées, y compris les cibles de redirection et la résolution DNS, afin d'empêcher les contournements habituels.

• Bloqué par défaut : les réseaux privés tels que 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16, les adresses de loopback telles que 127.0.0.0/8, les plages link-local ainsi que divers espaces d'adresses réservés.
• Étendre la liste de blocage : des plages supplémentaires peuvent être ajoutées via N8N_SSRF_BLOCKED_IP_RANGES, par exemple N8N_SSRF_BLOCKED_IP_RANGES=default,100.0.0.0/8.
• Définir des exceptions : N8N_SSRF_ALLOWED_HOSTNAMES autorise des noms d'hôtes, y compris avec des wildcards, N8N_SSRF_ALLOWED_IP_RANGES autorise certaines plages d'IP, l'ordre étant liste d'autorisation des noms d'hôtes avant liste d'autorisation des IP avant liste de blocage des IP.
• Ne remplace pas la sécurité réseau : la protection agit au niveau applicatif et complète les pare-feux et les security groups, mais ne les remplace pas selon la documentation.

Verrouiller les nodes à risque avec NODES_EXCLUDE

Tous les nodes ne conviennent pas à tous les groupes d'utilisateurs. La variable d'environnement NODES_EXCLUDE permet de définir une liste de types de nodes qui ne sont ni trouvables ni utilisables par aucun utilisateur de l'instance. La valeur est transmise sous forme de tableau JSON d'identifiants de nodes, par exemple NODES_EXCLUDE avec le contenu ["n8n-nodes-base.executeCommand", "n8n-nodes-base.readWriteFile"]. La documentation cite en particulier le node Execute Command et le node Read/Write Files from Disk comme candidats typiques pour les environnements où tous les utilisateurs ne sont pas entièrement dignes de confiance, car les deux permettent un accès direct au système hôte.

• Format : tableau JSON sous forme de chaîne, chaque entrée est le nom interne complet du node.
• Effet : les nodes bloqués ne peuvent être ni trouvés dans la recherche de nodes ni utilisés dans les workflows.
• Lever les blocages par défaut : certains nodes comme Execute Command sont déjà bloqués en usine ; qui veut les autoriser délibérément définit NODES_EXCLUDE explicitement sur un tableau vide.

Désactiver la Public API si personne n'en a besoin

La Public REST API de n8n permet de contrôler par programmation pratiquement tout ce qui est également possible via l'interface, c'est-à-dire créer des workflows, déclencher des exécutions ou gérer des identifiants. C'est précisément ce qui en fait une surface d'attaque supplémentaire lorsqu'elle reste active sans être utilisée. Via N8N_PUBLIC_API_DISABLED=true, vous désactivez complètement la Public API ; la documentation le recommande expressément si personne n'utilise réellement l'API. Qui a besoin de l'API mais ne souhaite pas montrer publiquement l'interface de documentation interactive peut en plus définir N8N_PUBLIC_API_SWAGGERUI_DISABLED=true, ce qui désactive uniquement le playground de l'API, l'API elle-même restant accessible.

• N8N_PUBLIC_API_DISABLED : désactive l'intégralité de la Public API.
• N8N_PUBLIC_API_SWAGGERUI_DISABLED : masque uniquement l'interface interactive Swagger, l'API elle-même continue de fonctionner.

Autres éléments de la documentation sur la sécurité

Les quatre points cités sont ceux qui offrent le plus grand levier au quotidien, mais ils ne couvrent pas l'ensemble du sujet. La documentation sur la sécurité de n8n traite en outre, entre autres, du Single Sign-On, de l'obligation de vérification par e-mail des nouveaux comptes, du chiffrement TLS pour la connexion, de la rotation régulière des clés de chiffrement, du déchiffrement JWE des tokens OAuth 2.0, du masquage des données d'exécution, de la sécurisation des task runners ainsi que de la désactivation de la télémétrie. n8n recommande en outre de lancer régulièrement un audit de sécurité intégré, qui vérifie automatiquement bon nombre de ces paramètres et liste les points ouverts. Qui ne souhaite pas gérer ces paramètres lui-même trouvera, dans le cadre de notre conseil n8n un accompagnement pour la mise en place et l'exploitation courante, en indiquant aussi honnêtement où l'automatisation seule ne suffit pas et où des règles organisationnelles au sein de l'équipe restent nécessaires.

Questions fréquentes sur le durcissement de la sécurité de n8n

Dois-je pouvoir imposer la 2FA à tous les utilisateurs ?

n8n active la fonction à l'échelle de l'instance via N8N_MFA_ENABLED, mais la configuration effective se fait par compte utilisateur dans les paramètres personnels. Un interrupteur central rendant la 2FA immédiatement obligatoire pour tous les comptes n'est pas décrit dans la documentation de base ; il reste donc de votre ressort d'imposer à l'équipe, sur le plan organisationnel, de l'activer.

La protection SSRF remplace-t-elle un pare-feu ?

Non. La protection SSRF agit au niveau applicatif et vérifie les requêtes sortantes des nodes de workflow ; elle complète ainsi les contrôles réseau tels que les pare-feux et les security groups, mais selon la documentation, elle ne les remplace expressément pas.

Quels nodes dois-je bloquer par défaut ?

La documentation cite le node Execute Command et le node Read/Write Files from Disk comme candidats typiques pour NODES_EXCLUDE, car tous deux permettent un accès direct au système hôte sous-jacent. Les autres nodes à risque dépendent de votre groupe d'utilisateurs concret.

Ai-je vraiment besoin de la Public API ?

Seulement si vous pilotez n8n par programmation, par exemple depuis vos propres scripts, d'autres systèmes ou des pipelines CI/CD. Si l'API n'est pas utilisée activement, la documentation recommande de la désactiver complètement via N8N_PUBLIC_API_DISABLED.

Sources : Vue d'ensemble sécurité n8n, Authentification à deux facteurs, Activer la protection SSRF, Bloquer des nodes, Désactiver la Public API