Comment durcir n8n : activer la 2FA, mettre en place la protection SSRF, verrouiller les nodes à risque avec NODES_EXCLUDE et désactiver la Public API si elle n'est pas utilisée.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
NordFlux construit des employés numériques pour les organisations : des automatisations et des agents KI qui prennent en charge le travail répétitif. Vous gardez le contrôle.
Les Task Runners n8n exécutent les nœuds Code de manière isolée plutôt que dans le processus principal. Voici comment fonctionnent les modes interne et externe.
Passer de self-hosted au n8n Cloud : l'effort de maintenance diminue, mais le controle aussi. Ce qui ne suit pas automatiquement au niveau des nodes et des identifiants.
Shopware 6 n'a pas de node n8n natif. Voici comment connecter les commandes, les clients et le stock via l'Admin API et le HTTP Request Node.
2FA, protection SSRF et nodes bloqués ne sont qu'un début : une instance n8n sûre exige un suivi permanent, des mises à jour et une attention à chaque nouvelle surface d'attaque. NordFlux exploite n8n en service géré et prend en charge durcissement, supervision et mises à jour pour vous. Lors d'un premier échange, nous identifions les points où votre instance est aujourd'hui vulnérable.
