TL;DR
La sécurité des automatisations no-code se joue moins sur l’outil choisi que sur ce que chaque workflow a le droit de faire. Un scénario n8n, Make, Zapier ou Power Automate détient des jetons d’accès vers votre CRM, votre messagerie et vos fichiers, souvent avec des droits plus larges que ceux de la personne qui l’a créé. Les agents IA no-code comme Copilot Studio ajoutent un vecteur nouveau : l’injection de prompt.
Cloisonner les identifiants, authentifier les webhooks, inventorier les flux et surveiller leurs actions réduit nettement l’exposition. Seul un test d’intrusion montre jusqu’où un attaquant irait réellement à partir d’un workflow compromis.
24 700
instances n8n exposées sur Internet début 2026, dont environ 7 800 en Europe
9,9
score CVSS de CVE-2025-68613, première faille n8n au catalogue CISA des vulnérabilités exploitées
5
plateformes passées en revue : n8n, Make, Zapier, Power Automate, Copilot Studio
Un formulaire de contact qui crée une fiche dans le CRM. Une facture reçue par mail qui part dans le dossier comptable. Un prospect enrichi automatiquement puis ajouté à une séquence de prospection. En quelques années, les outils d’automatisation no-code sont devenus la colle invisible entre les applications d’une entreprise.
Cette colle a une particularité : pour fonctionner, elle a besoin des clés de toutes les pièces qu’elle relie. Chaque workflow stocke des jetons OAuth, des clés d’API, des identifiants de base de données. Il s’exécute seul, la nuit comme le jour, sans session interactive et souvent sans que l’équipe informatique sache qu’il existe.
C’est un prolongement direct du Shadow IT : des applications et des flux qui vivent hors de l’inventaire, et que seule une cartographie du système d’information confrontée au terrain fait apparaître. Cet article passe en revue les cinq plateformes les plus répandues en 2026, leurs angles morts, les bonnes pratiques à appliquer, et ce qu’un test d’intrusion révèle quand une organisation pense avoir tout sécurisé.
Risque
Pourquoi la sécurité des automatisations no-code est un sujet à part
Un workflow est un compte à privilèges qui ne dort jamais
Trois propriétés distinguent une automatisation d’une application classique, et expliquent pourquoi elle mérite un traitement de sécurité spécifique.
Elle concentre les secrets
Une plateforme d’automatisation centralise les connexions vers des dizaines de services. Compromettre la plateforme, ou un seul compte qui y a accès, revient à récupérer d’un coup les accès au CRM, à la messagerie, au stockage cloud et à la facturation.
Elle agit sous une identité empruntée
Le référentiel OWASP Low-Code/No-Code Top 10 place ce risque en tête (« Account Impersonation ») : un flux utilise le compte de son créateur, et ses actions apparaissent dans les journaux comme si cette personne les faisait elle-même.
Elle échappe à l’inventaire
N’importe quel collaborateur peut créer un workflow en dix minutes. Personne ne le documente, personne ne le révoque au départ de son auteur. Les jetons accordés continuent de fonctionner.
Le projet OWASP a depuis été élargi en OWASP Citizen Development Top 10 pour couvrir aussi le code assisté par IA et les agents IA. Il complète le Top 10 OWASP des applications web, qui reste pertinent pour l’interface et les API des plateformes elles-mêmes.
Un risque devenu concret en 2026
Le 11 mars 2026, la CISA a ajouté la vulnérabilité n8n CVE-2025-68613 (CVSS 9,9) à son catalogue des failles exploitées dans la nature. C’est la première entrée n8n de ce catalogue. La Shadowserver Foundation comptait alors plus de 24 700 instances exposées sur Internet (source). Ce type d’inventaire public, un attaquant le reproduit en quelques minutes avec des moteurs comme Shodan.
Le message n’est pas « n8n est dangereux ». C’est qu’une plateforme d’automatisation est désormais une cible à part entière, au même titre qu’un VPN ou une messagerie, et qu’elle se protège comme telle.
Chaîne type : un workflow compromis donne accès à tout ce qu’il relie
Les 5 outils d’automatisation et leurs angles morts
Chaque plateforme a son propre modèle de risque
Là où n8n expose surtout son serveur, Zapier et Make exposent surtout vos connexions, et Power Automate ou Copilot Studio exposent votre tenant Microsoft 365. Le tableau résume, les cartes détaillent.
Auto-hébergé
n8n : le serveur est la cible
Fin 2025 et début 2026, plusieurs failles critiques ont été publiées. CVE-2026-21858 (CVSS 10) permettait d’accéder aux fichiers du serveur sans authentification via un formulaire public (Cybersecurity Dive). Combinée à une faille d’exécution de code, elle livre tous les identifiants stockés (VulnCheck).
SaaS
Make : des portes ouvertes par défaut
Une URL de webhook accepte toute requête tant qu’aucune authentification (clé en en-tête, signature) n’est activée. Le module HTTP peut envoyer des données vers n’importe quelle adresse : un scénario modifié par un compte compromis lit vos données et les sort sans alerte.
SaaS
Zapier : les secrets là où on ne les cherche pas
En février 2025, un attaquant a exploité une mauvaise configuration de double authentification d’un employé pour accéder à des dépôts de code contenant des données clients. Zapier a recommandé de renouveler les jetons en clair des étapes Code et Webhook (TechRadar).
Microsoft 365
Power Automate : activé pour tous
Tout utilisateur Microsoft 365 peut créer des flux. Varonis a montré qu’un compte compromis suffit pour transférer mails et fichiers SharePoint vers l’extérieur en contournant les règles classiques de prévention des fuites (Varonis). Le flux survit au changement de mot de passe.
Agent IA
Copilot Studio : le workflow obéit à un texte
Tenable a fait contourner à un agent de réservation ses contrôles d’identité et ramener un prix à 0 dollar par simple injection de prompt (SecurityBrief). Zenity a exfiltré des données CRM via un agent qui lisait des mails (Zenity Labs).
Synthèse
Le point commun
Dans chaque cas, l’attaquant n’a pas besoin de « casser » l’outil : il utilise ce que le workflow a déjà le droit de faire. Avec un agent IA, il lui suffit parfois de lui écrire. Le niveau de risque dépend donc d’abord des droits accordés.
Le scénario Power Automate rejoint ce que nous décrivons dans l’exploitation des usages cloud par les attaquants en 2026 : l’attaquant ne déploie plus de logiciel malveillant, il se sert des fonctions légitimes du service. Pour l’usage de l’IA côté offensif, voir aussi notre article sur l’IA dans les tests d’intrusion.
Bonnes pratiques
Sécuriser vos automatisations no-code : 8 mesures concrètes
Applicables quel que soit l’outil, dans l’ordre du Top 10 OWASP Low-Code/No-Code
Tenir un inventaire des workflows
Pour chaque flux : auteur, propriétaire actuel, services connectés, données manipulées, date de dernière modification. Sans inventaire, aucune des mesures suivantes n’est vérifiable. Revue au minimum trimestrielle.
Utiliser des comptes de service dédiés
Un workflow critique ne tourne pas sous le compte personnel de son créateur. Un compte technique par usage, avec uniquement les droits nécessaires : lecture seule si le flux ne fait que lire.
Réduire la portée des connexions
Lors d’une autorisation OAuth, refusez les permissions globales quand une permission restreinte existe : un seul dossier plutôt que tout le Drive, une seule boîte plutôt que toute la messagerie.
Authentifier chaque webhook
Activez la clé d’API en en-tête ou la vérification de signature HMAC sur Make, n8n et Zapier, et filtrez les adresses IP quand l’émetteur en a de fixes. Une URL de webhook n’est pas un secret : elle finit dans des journaux, des exports, parfois indexée et retrouvée par des requêtes de type Google Dorks.
Sortir les secrets des étapes de workflow
Aucune clé d’API collée en clair dans une étape Code, HTTP ou Webhook. Utilisez le gestionnaire d’identifiants natif ou un coffre externe, avec un calendrier de renouvellement. Les principes de notre politique de mots de passe s’appliquent aussi aux comptes des plateformes, double authentification comprise.
Durcir les instances auto-hébergées
Pour n8n : mise à jour dans les jours qui suivent un avis de sécurité, interface d’administration non exposée sur Internet (VPN ou proxy authentifié), authentification multifacteur, création de workflows réservée à quelques personnes, nœuds d’exécution de code désactivés si inutiles.
Encadrer Power Automate et Copilot Studio
Dans le centre d’administration Power Platform, classez les connecteurs en groupes « Professionnel », « Non professionnel » et « Bloqué ». Pour les agents IA : actions étroites (un enregistrement précis plutôt qu’une table entière) et validation humaine sur toute action financière.
Journaliser et surveiller les actions des flux
Alertez sur la création d’un flux qui transfère des mails, une connexion vers un domaine externe inconnu, un pic de données sortantes. Un EDR ne voit rien de ces actions : elles se déroulent dans le cloud, pas sur un poste.
Un workflow qui touche des données sensibles mérite le même passage par la case sécurité qu’une application avant sa mise en ligne. Voir notre article sur le test de sécurité avant mise en production.
Terrain
Erreurs fréquentes observées
Ce qui reste ouvert dans des environnements jugés « propres »
Le workflow orphelin
Son auteur a quitté l’entreprise, son compte est désactivé dans l’annuaire, mais les jetons OAuth accordés à la plateforme fonctionnent toujours. Le flux tourne, plus personne ne le connaît.
Le compte « admin » partagé
Un seul compte partagé par le marketing, les commerciaux et un prestataire, sans double authentification. Il voit toutes les connexions et devient la cible idéale d’une campagne d’hameçonnage.
L’instance de test devenue production
Une instance n8n lancée sur un VPS pour essayer, branchée au CRM « en attendant », jamais mise à jour et accessible depuis Internet.
La confiance aveugle dans les entrées
Un formulaire public alimente un workflow qui écrit en base, envoie un mail ou déclenche un agent IA, sans validation du contenu. C’est le vecteur des failles n8n de 2026 et des injections de prompt.
Le DLP configuré une fois
Une politique de prévention des fuites posée au déploiement de Power Platform, puis jamais revue : les connecteurs ajoutés depuis restent dans le groupe par défaut.
L’export de workflow partagé tel quel
Un modèle de scénario envoyé à un collègue, un freelance ou publié sur un forum, avec les clés d’API encore dedans. Un cas typique de vulnérabilité cachée que personne ne cherche.
Test d’intrusion
Vue test d’intrusion : ce que des automatisations « bien configurées » laissent passer
La différence entre une configuration conforme et une configuration qui résiste
Une politique DLP active, des webhooks authentifiés et un n8n à jour ne disent rien de l’impact réel d’une compromission. C’est la question à laquelle répond un test d’intrusion : à partir d’un point d’entrée réaliste, jusqu’où un attaquant irait-il ?
Un test d’intrusion couvre-t-il les outils no-code ?
Oui, à condition de les inscrire explicitement au périmètre. Une plateforme d’automatisation se teste à la fois comme une application web (interface, formulaires publics, webhooks), comme une API (appels émis et reçus, gestion des jetons, voir notre article sur les attaques JWT) et, quand elle est auto-hébergée, comme un serveur du système d’information. Un scanner automatique ne fait pas ce travail : c’est toute la différence entre test d’intrusion et scan de vulnérabilités.
Ce que nos testeurs vérifient
La surface exposée réelle
Instances, formulaires et webhooks accessibles depuis Internet, comparés à ce que l’inventaire déclare. Les écarts sont examinés en priorité.
La valeur d’un compte compromis
Depuis un compte standard fourni en boîte grise : connexions réutilisables, secrets lisibles dans les workflows, possibilité de créer un flux d’exfiltration.
La robustesse des entrées
Comportement d’un workflow face à des données inattendues, interceptées et rejouées avec des outils comme Burp Suite. Pour les agents IA, résistance aux instructions cachées dans un mail ou un document.
Le rayon d’action
Les services atteints ensuite avec les jetons récupérés : CRM, messagerie, stockage, outils financiers. C’est ce qui transforme une faille en impact métier.
La détection
Si la création d’un flux suspect ou une sortie de données inhabituelle aurait été repérée, et en combien de temps.
Le cadre
Chaque vérification est menée dans un périmètre contractuel défini, sans action destructive, et documentée pour être rejouée après correction.
Le bon périmètre selon votre usage
La sécurité des automatisations no-code relève du même partage de responsabilité que vos applications SaaS : l’éditeur sécurise sa plateforme, vous sécurisez ce que vous y branchez. Un test d’intrusion vérifie votre part. Pour un suivi plus fréquent sur un parc de workflows qui évolue vite, une approche PTaaS peut compléter un test ponctuel, sans remplacer l’analyse humaine des enchaînements.
Testez votre exposition
Que ferait un attaquant avec l’un de vos workflows ?
Un test d’intrusion PIIRATES identifie les points d’entrée de vos automatisations et démontre leur impact réel sur les services connectés.
Demander un test d’intrusionPas par nature. Ils déplacent le risque : moins de code à écrire soi-même, mais plus de secrets centralisés, plus de workflows créés hors de l’équipe informatique et moins de revue avant mise en production.
La version cloud vous décharge des mises à jour du serveur. La version auto-hébergée vous laisse le contrôle des données mais vous rend responsable des correctifs et de l’exposition réseau. Les failles critiques de 2026 ont surtout touché des instances auto-hébergées non mises à jour.
Rarement. Une désactivation pousse souvent les équipes vers des outils non maîtrisés, ce qui nourrit le Shadow IT. Mieux vaut des politiques DLP par environnement, un environnement dédié aux flux critiques et une surveillance des créations de flux.
Non. Une URL finit dans des journaux, des historiques de navigateur, des captures d’écran ou des exports. Seule une authentification (clé en en-tête, signature) garantit l’origine de la requête.
C’est le fait de glisser des instructions dans un contenu que l’agent lit (un mail, un document, un champ de formulaire) pour lui faire exécuter une action non prévue, comme divulguer des données ou modifier un enregistrement. Le risque grandit avec les droits accordés à l’agent.
Le Top 10 OWASP Low-Code/No-Code place en tête l’usurpation d’identité par les comptes intégrés, le mauvais usage des autorisations et les fuites de données. Suivent les défauts d’authentification, les erreurs de configuration, l’injection, les composants non fiables, la gestion des secrets, l’inventaire et la journalisation.
Oui dès qu’il manipule des données sensibles ou expose un point d’entrée public. La logique est la même que pour une application, détaillée dans notre article sur le test de sécurité avant mise en production.
Oui, s’ils sont inscrits au périmètre. Le test porte sur les points d’entrée exposés, les droits des connexions et ce qu’un compte compromis permet d’atteindre. Il se combine avec un test d’intrusion web ou un test d’intrusion SI.
n8n, Make, Zapier, Power Automate, Copilot Studio : ce que vos workflows exposent, 8 mesures pour les sécuriser et ce qu’un test d’intrusion révèle.
