Sécuriser les credentials n8n : bonnes pratiques de gestion des clés API

Les credentials sont le maillon le plus sensible d'un workflow n8n : une clé API OpenAI, un token Stripe, un mot de passe de base de données — tout ce qui donne accès à un système externe transite par là. n8n les chiffre correctement par défaut, mais « chiffré par défaut » ne veut pas dire « sans risque si on l'ignore ». Voici comment gérer ces credentials sérieusement, du chiffrement de base à la rotation en production.

Comment n8n chiffre vos credentials

Chaque credential enregistré dans n8n est chiffré au repos avec l'algorithme AES, en utilisant une clé unique propre à votre instance : la N8N_ENCRYPTION_KEY. Cette clé est générée automatiquement au premier démarrage si vous ne la définissez pas vous-même, et stockée localement (dans ~/.n8n/config en self-hosted classique). C'est elle, et uniquement elle, qui permet à n8n de déchiffrer vos credentials pour exécuter un workflow.

Concrètement, cela veut dire que la base de données de n8n (Postgres ou SQLite selon votre installation) ne contient jamais vos clés API en clair, même si quelqu'un y accède directement. C'est une bonne nouvelle pour la sécurité au repos, mais ça crée aussi un point de défaillance unique qu'il faut traiter avec sérieux.

Ne perdez jamais votre clé de chiffrement

C'est le piège numéro un du self-hosted : la N8N_ENCRYPTION_KEY n'est sauvegardée nulle part par défaut en dehors de l'instance elle-même. Si vous perdez le serveur, le volume Docker, ou simplement le fichier de config sans l'avoir copiée ailleurs, tous les credentials existants deviennent définitivement illisibles. Pas « difficiles à récupérer » — illisibles, point final. Il faut alors recréer chaque credential à la main dans chaque workflow concerné.

La parade est simple et doit faire partie de votre check-list de mise en production :

• Fixez la valeur vous-même au lieu de laisser n8n la générer, via la variable d'environnement N8N_ENCRYPTION_KEY définie avant le premier démarrage.
• Sauvegardez-la séparément de la base de données n8n : un gestionnaire de mots de passe d'équipe, un coffre-fort de secrets, jamais un fichier texte dans le même dossier que le reste.
• Incluez-la dans votre procédure de disaster recovery, au même titre que les sauvegardes de workflows décrites dans notre guide versionner ses workflows n8n avec Git — un export de workflows sans la clé de chiffrement associée ne restaure pas les credentials qui vont avec.

Credentials dans l'UI vs variables d'environnement

n8n propose deux façons de fournir un secret à un workflow, et elles ne servent pas le même usage.

Les credentials stockés dans l'UI sont l'option par défaut et la bonne pour l'immense majorité des cas : une clé API OpenAI, un token Slack, des identifiants de base de données. Ils sont chiffrés avec la N8N_ENCRYPTION_KEY, réutilisables entre plusieurs workflows, et surtout gérables par les permissions n8n — vous pouvez les partager avec une équipe sans exposer la valeur elle-même.

Les variables d'environnement (accessibles via $env dans les expressions et nodes Code) conviennent mieux aux secrets globaux à l'instance : la clé de chiffrement elle-même, l'accès à un secrets manager externe, une configuration qui ne change jamais et qui s'applique à toute l'installation plutôt qu'à un workflow métier précis. Elles ne bénéficient pas du même système de partage granulaire que les credentials UI, donc les réserver aux vrais secrets d'infrastructure évite de perdre le contrôle sur qui voit quoi.

Qui peut voir quoi : permissions et partage d'équipe

Sur n8n Cloud (offres Team et au-delà) et sur n8n Enterprise self-hosted, les credentials s'organisent en projects : chaque credential appartient à un projet, et seuls les membres ayant accès à ce projet peuvent l'utiliser dans un workflow. Un credential peut aussi être partagé individuellement avec un utilisateur ou un rôle précis, sans lui donner accès à l'ensemble du projet.

Le principe à appliquer : le moindre privilège. Un freelance qui construit un workflow de scraping n'a pas besoin de voir le credential Stripe de production. Sur les instances n8n en version Community (sans projects), cette granularité n'existe pas — tous les utilisateurs avec accès instance peuvent potentiellement utiliser tous les credentials, ce qui est un argument de poids pour passer à Enterprise ou Cloud Team dès qu'une équipe de plus de deux ou trois personnes partage la même instance.

Faire tourner une clé API sans casser la prod

La rotation régulière des clés API est une hygiène de base, souvent repoussée parce qu'elle fait peur — « et si ça casse un workflow en prod ? ». Avec n8n, la manœuvre est en réalité simple parce que le credential est un objet indépendant du workflow :

1. Générez la nouvelle clé chez le fournisseur (OpenAI, Stripe, etc.) sans révoquer l'ancienne tout de suite.
2. Ouvrez le credential existant dans n8n et remplacez la valeur — tous les nodes qui référencent ce credential basculent automatiquement, sans toucher à un seul workflow.
3. Lancez une exécution de test sur un workflow représentatif pour confirmer que la nouvelle clé fonctionne.
4. Révoquez l'ancienne clé côté fournisseur une fois la bascule confirmée.

Le point clé : vous ne modifiez jamais les workflows, seulement le contenu du credential. C'est pour ça qu'il ne faut jamais dupliquer une clé API en dur dans plusieurs nodes — la rotation devient sinon une chasse au trésor dans tous vos workflows au lieu d'une modification en un seul endroit.

Éviter les fuites : le piège du node Code

Le risque le plus sournois n'est pas le vol de credential, c'est la fuite accidentelle. Une clé API collée en dur dans un node Code au lieu d'être référencée via $credentials, ou une expression du type {{ $json.apiKey }} qui affiche la valeur en clair dans le panneau d'exécution — les deux se retrouvent potentiellement visibles dans les logs d'exécution, dans un export JSON du workflow partagé avec un collègue, ou dans une capture d'écran envoyée pour du support.

Le phénomène est massif et documenté : une étude de Meli, McNiece et Reaves, présentée au NDSS Symposium en 2019, a analysé des milliards de fichiers publics sur GitHub et détecté des centaines de milliers de dépôts contenant des secrets exposés par erreur (clés API, tokens, identifiants de base de données), avec plusieurs milliers de nouveaux secrets qui fuitent chaque jour (Meli, McNiece & Reaves, 2019, NDSS Symposium). Un export de workflow n8n partagé sans précaution, ou poussé par erreur dans un dépôt Git public, reproduit exactement ce scénario à l'échelle d'une seule entreprise.

Quelques réflexes simples évitent l'essentiel des fuites :

• Toujours référencer un secret via un credential dédié au node (HTTP Request, Postgres, Slack…), jamais en variable en dur dans un node Set ou Code.
• Si un node Code a réellement besoin d'un secret, le lire depuis $env (variable d'environnement) plutôt que de le coller dans le script.
• Vérifier, avant de partager un export de workflow ou une capture d'écran, qu'aucune valeur de credential n'apparaît dans les champs visibles ou dans les données d'exécution affichées.
• Traiter tout webhook entrant avec la même rigueur que décrite dans notre guide sécuriser un webhook n8n exposé publiquement : un credential bien protégé ne sert à rien si l'accès au workflow lui-même est ouvert à tous.

Auditer les credentials utilisés par workflow

Avant une mise en production ou un audit de sécurité, il est utile de savoir précisément quel workflow utilise quel credential — et surtout, quels credentials ne sont plus utilisés par personne. n8n liste les credentials par type et par nom dans son interface, mais ne fournit pas nativement une vue croisée « credential → workflows qui l'utilisent ». En self-hosted avec accès à la base de données, une requête sur la table credentials_entity croisée avec les nœuds des workflows exportés permet de reconstruire cette cartographie.

Cet audit rejoint la logique de la piste d'audit RGPD avec n8n et Supabase : savoir qui a accès à quoi, et le prouver, fait partie des bonnes pratiques attendues dès qu'un workflow touche des données sensibles ou des systèmes de paiement.

Self-hosted : variables d'environnement et secrets manager externe

En self-hosted, vous avez une couche de contrôle supplémentaire que n8n Cloud ne vous donne pas : l'accès direct au serveur. Cela permet de renforcer encore la gestion des secrets :

• Isoler les variables d'environnement sensibles dans un fichier .env non versionné, jamais commité dans le dépôt Git de votre configuration d'infrastructure.
• Chiffrer le volume disque qui héberge la base de données n8n, en complément du chiffrement applicatif déjà assuré par la N8N_ENCRYPTION_KEY.
• Brancher un secrets manager externe (HashiCorp Vault, AWS Secrets Manager) pour les organisations qui ont déjà une politique de rotation automatisée à l'échelle de l'infrastructure — n8n peut alors récupérer certaines valeurs via un node Code ou HTTP Request au démarrage d'un workflow, plutôt que de les stocker localement. Une complexité à ne considérer que si elle existe déjà ailleurs dans votre stack.

Cet arbitrage entre simplicité et contrôle est le même que celui détaillé dans notre comparatif n8n self-hosted vs cloud : plus de contrôle, mais aussi plus de responsabilité opérationnelle sur la sécurité des secrets.

En résumé

La sécurité des credentials n8n repose sur peu de règles, mais elles ne pardonnent pas si on les ignore : sauvegarder la N8N_ENCRYPTION_KEY séparément, réserver les variables d'environnement aux secrets d'infrastructure, cloisonner les accès par projet, faire tourner les clés API via le credential plutôt qu'en dur dans les nodes, et auditer régulièrement qui utilise quoi. Si vous partez d'une instance neuve, la meilleure friction est la plus basse : appliquer ces réflexes dès le premier credential créé coûte quelques minutes, les corriger après une fuite coûte beaucoup plus.