Étude de cas : un webhook n8n ouvrait les comptes administrateur

Chiffres clés

Contexte : que s'est-il passé sur cette plateforme de formation ?

Une plateforme française de formation en ligne (TPE), accessible sur invitation uniquement, a fait l'objet d'un audit externe début 2026. Le constat tient en une phrase : un simple webhook n8n, appelable par n'importe qui, permettait de créer des comptes avec le niveau d'accès de son choix alors que l'inscription publique était désactivée.

La plateforme combinait trois briques courantes : une application web monopage, un backend Supabase (base Postgres, authentification, API générées) et un serveur n8n pour automatiser les tâches d'administration, comme la création de comptes. L'équipe avait désactivé l'inscription publique, vérifié l'accès aux données en lecture et sécurisé le paiement. Sur le papier, la plateforme était fermée. Dans les faits, une porte annexe, construite pour la commodité de l'administrateur, contournait toutes ces protections.

Cette étude de cas est anonymisée. Nous ne nommons ni le client, ni son produit, ni son hébergement, et nous ne publions aucun élément qui permettrait de reproduire l'attaque.

Périmètre et autorisation : dans quel cadre l'audit a-t-il eu lieu ?

L'audit était une mission autorisée, payée, en lecture seule et conduite depuis l'extérieur, avec le point de vue d'un visiteur ou d'un attaquant sans compte. Aucun compte n'a été créé et aucune donnée n'a été modifiée.

Voici les règles que nous appliquons à ce type de mission :

• Seules les ressources servies publiquement ont été analysées : pages, fichiers JavaScript, réponses des API.
• Les endpoints de création de compte n'ont pas été appelés. La preuve de concept reposait sur la lecture du code envoyé au navigateur.
• Un seul des webhooks a reçu une requête vide, afin de confirmer qu'il répondait sans authentification. Cette action est consignée dans le rapport.
• Aucune donnée personnelle n'a été téléchargée ni conservée. Les tests s'arrêtent à la confirmation de lisibilité.
• Les fichiers temporaires ont été supprimés en fin de mission.

Cette discipline compte autant que la trouvaille. Un rapport doit prouver le risque sans le réaliser.

Ce que nous avons trouvé : quatre constats, dont un critique

Le constat critique est un webhook de création de compte sans aucune authentification, dont l'adresse était écrite dans le code du site. Trois autres constats de gravité moyenne l'aggravaient.

1. Critique : création de compte non authentifiée. L'interface d'administration envoie les informations du futur utilisateur (adresse, nom, mot de passe, niveau d'accès) à un webhook n8n. Aucun en-tête d'authentification, aucun jeton. L'adresse du webhook figurait dans un fichier JavaScript téléchargeable par tout visiteur.
2. Moyen : règles de sécurité manquantes en modification et en suppression. Au niveau de la base, les politiques de sécurité par ligne (RLS) bloquaient l'insertion mais aucune politique ne couvrait la mise à jour ni la suppression.
3. Moyen : trois webhooks n8n appelables publiquement. Leurs adresses étaient toutes présentes dans le code du site. Un test avec une requête vide a confirmé qu'un workflow démarrait sans contrôle.
4. Moyen : serveur n8n directement exposé sur internet. Le serveur était à jour au moment de l'audit, mais une instance d'automatisation joignable de partout reste une surface d'attaque permanente.

Le premier constat est celui qui fait mal. Les trois autres expliquent pourquoi il devenait si grave.

La chaîne d'attaque : comment passer de visiteur anonyme à administrateur ?

La chaîne se déroule en trois étapes conceptuelles et, d'après notre analyse, demande moins de deux minutes à un attaquant motivé. Nous ne l'avons pas exécutée de bout en bout, par respect de la règle de lecture seule, mais chaque maillon a été vérifié séparément.

1. Découverte. Le code de l'interface d'administration, servi publiquement, contient l'adresse du webhook et la forme exacte des données attendues. Il suffit de lire ce code.
2. Création d'un compte privilégié. Le webhook accepte la demande sans vérifier qui l'envoie. L'attaquant choisit le niveau d'accès, y compris le niveau le plus élevé du produit. L'inscription publique étant désactivée, ce webhook devient la seule porte d'entrée, et elle est grande ouverte.
3. Élévation de privilèges. Une fois connecté, l'utilisateur peut modifier ses propres droits. La table des rôles n'avait aucune politique RLS de mise à jour : la base acceptait la requête sans erreur de sécurité. Le compte devient administrateur, avec accès aux profils, aux sessions d'accompagnement, aux achats et aux journaux de connexion.

Aucun de ces maillons n'est sophistiqué. C'est leur combinaison qui crée la prise de contrôle complète. Chaque équipe aurait raisonnablement classé le constat 2 comme moyen en l'isolant, et c'est précisément pourquoi un audit doit enchaîner les constats plutôt que les lister.

Ce qui tenait : quels contrôles fonctionnaient bien ?

Plusieurs protections étaient correctement en place, et le rapport les mentionne, parce qu'un audit honnête décrit aussi ce qui résiste.

• La lecture des données était verrouillée. La très grande majorité des tables renvoyaient un résultat vide à un visiteur anonyme. Les contournements classiques (requêtes GraphQL, jointures via l'API) n'ont rien donné.
• L'insertion était bloquée sur toutes les tables.
• Le webhook du prestataire de paiement vérifiait la signature des appels entrants. C'est le bon modèle, et le contraste est frappant : sur le même serveur n8n, un webhook était protégé et un autre ne l'était pas.
• L'API REST de n8n était protégée : toutes les requêtes non authentifiées étaient refusées.
• Les liens de connexion par e-mail et la réinitialisation de mot de passe ne révélaient rien exploitable, et aucun secret de paiement n'apparaissait dans le code du site.

Ces points montrent une équipe sensibilisée. Le défaut tient à un angle mort : les automatisations internes n'étaient pas considérées comme une surface d'attaque.

Correctifs : que recommander à une TPE ?

Les corrections sont peu coûteuses et s'appliquent en quelques heures à quelques jours. Nous les avons classées par urgence.

Immédiat

• Authentifier chaque webhook n8n avec un secret que seul le serveur de l'application connaît. n8n propose des méthodes d'authentification natives sur le nœud Webhook.
• Ajouter des politiques RLS de mise à jour et de suppression sur toutes les tables, en commençant par la table des rôles.

Cette semaine

• Déplacer les opérations d'administration côté serveur (fonction serveur ou Edge Function vérifiant l'identité de l'administrateur) afin que le navigateur n'appelle plus jamais le webhook directement.
• Retirer les adresses des webhooks et tout secret du code envoyé au navigateur.
• Restreindre l'accès réseau au serveur n8n (VPN, liste d'adresses autorisées) pour qu'il ne soit plus exposé publiquement.

Ce mois-ci

• Appliquer le moindre privilège : un utilisateur connecté ne doit pouvoir modifier ni son rôle, ni ses droits.
• Revoir les politiques RLS des comptes authentifiés, pas seulement des visiteurs anonymes.

Ce que ça change pour un agent IA : pourquoi cette étude de cas nous concerne

Un workflow ou un webhook n8n est exactement le type d'outil qu'un agent IA appelle. Si le contrôle d'accès manque sur ce point d'entrée, le même défaut devient une action qu'un agent peut déclencher, y compris sous l'influence d'un texte malveillant.

Dans le cas présent, c'est un humain qui lisait le code pour trouver le webhook. Remplaçons-le par un agent connecté à ses outils par appels de fonctions ou par un serveur MCP. L'agent reçoit un e-mail, un document ou une page web contenant des instructions cachées (injection de prompt indirecte). Parmi ses outils figure « créer un utilisateur », branché sur un webhook ouvert. Aucun humain ne valide l'action, aucune authentification ne distingue la demande légitime de la demande injectée. C'est le scénario que le référentiel OWASP appelle agence excessive (LLM06 dans le Top 10 for LLM Applications 2025).

Trois enseignements se transposent directement :

• La barrière de sécurité doit exister hors de l'agent. Les règles écrites dans un prompt sont souples. La décision d'autoriser une action doit vivre dans le système qui l'exécute, avec authentification, périmètre limité et journalisation.
• Chaque outil d'un agent est une surface d'attaque. Le serveur MCP, le webhook ou le workflow doit vérifier l'appelant et le droit d'agir, comme le ferait une API exposée publiquement.
• Les chaînes comptent plus que les constats isolés. Un outil permissif, une base trop ouverte et une instruction injectée suffisent à produire un incident.

Pour approfondir, consultez notre page sur la sécurité des agents IA, celle consacrée à la sécurité MCP et notre approche du red team d'agent IA. L'offre Red Team Agent Express applique cette logique de chaîne à votre agent en cinq jours.

Résultat : qu'a obtenu le client ?

Le client a reçu un rapport complet, une note de synthèse destinée à la direction avec les priorités du jour, de la semaine et du mois, et la liste des contrôles qui fonctionnaient. Les constats critiques ont été présentés avec leur chaîne d'exploitation pour que la correction vise la cause (l'absence de contrôle d'accès) et le symptôme visible (une adresse visible).

Le point à retenir pour toute équipe qui automatise avec n8n, Make ou Zapier : inventoriez chaque webhook, vérifiez qui peut l'appeler, et traitez l'automatisation comme une API publique. Si un agent IA s'appuie sur ces automatisations, ce travail devient la première ligne de défense de votre agent.

Pour aller plus loin

• Autre étude de cas : un paywall Supabase contourné en deux requêtes

Et après : le contre-test

Nous sommes revenus sur cette plateforme quelques semaines plus tard, dans le cadre d'un second test d'intrusion autorisé, avec le même point de vue : un attaquant externe anonyme, sans compte, l'inscription restant désactivée. La question était directe : le correctif de la faille critique tient-il, et qu'a-t-on laissé ouvert ailleurs ?

Ce qui était corrigé. La création de compte sans authentification, point d'entrée de toute la chaîne, n'existe plus. Les adresses des webhooks ont disparu du code JavaScript servi aux visiteurs, et la création de compte passe désormais par une fonction côté serveur qui vérifie l'identité et le rôle de l'appelant avant d'agir. Les politiques de sécurité manquantes en modification et en suppression sont également en place : une tentative anonyme de modifier ou de supprimer une ligne n'affecte plus rien. La lecture des contenus de formation, auparavant partiellement ouverte, renvoie maintenant des résultats vides. Le schéma exposé par l'API a été en grande partie masqué, avec un reliquat côté requêtes génériques.

Ce qui restait. Le contre-test s'est conclu sur zéro constat critique, un constat élevé, huit moyens et cinq bas. Le constat élevé tient en une phrase : l'extension de navigateur proposée au public embarquait les adresses de trois webhooks d'automatisation sans authentification. N'importe qui pouvait utiliser gratuitement des fonctions payantes, au détriment du propriétaire qui paie la consommation, et déclencher des e-mails de connexion. Le correctif avait été appliqué au site, mais pas à cette seconde surface.

Les constats moyens relèvent d'une hygiène de plateforme : limitation insuffisante des tentatives de connexion et de vérification, contenu payant accessible par un lien public, écriture anonyme possible dans un journal d'erreurs, contrôle d'origine contournable sur la diffusion vidéo, en-têtes de sécurité absents, enregistrement public de clients sur le serveur d'automatisation. Neuf autres pistes, liées à la logique métier, n'ont pas pu être confirmées sans compte.

La leçon. Corriger une faille, c'est fermer une porte. Le contre-test a montré que la même erreur de conception, des automatisations appelables par n'importe qui, subsistait ailleurs sous une autre forme. Pour un agent IA, le même réflexe vaut : chaque outil, chaque webhook et chaque extension est une entrée à authentifier. Nous recommandons un inventaire complet des points d'entrée après tout correctif, puis un nouveau test. Voir aussi le Red Team Agent Express.

Les autres études de cas

• Paywall Supabase contourné en deux requêtes
• Application SaaS de rédaction IA
• Plateforme d’échange de crypto-actifs
• Restaurant : back-office ouvert par un fichier oublié