Le problème des webhooks no-code
Zapier et Make ont démocratisé l'automatisation. Des millions d'entreprises les utilisent pour connecter leurs applications, synchroniser leurs données et automatiser leurs workflows.
Mais voici ce que personne ne vous dit : chaque webhook que vous créez est une porte potentiellement ouverte sur vos systèmes.
⚠️ Cas réel - Décembre 2025
Une agence marketing utilisait Zapier pour envoyer les leads de son site vers son CRM. Le webhook était public, sans authentification. Un concurrent a découvert l'URL et a envoyé 10 000 faux leads en une nuit. Résultat : base de données corrompue, 3 jours de nettoyage manuel, et une facture Zapier de 847€.
Ce guide vous montre exactement comment sécuriser vos webhooks Zapier et Make, même si vous n'êtes pas développeur.
Pourquoi vos webhooks sont vulnérables
Quand vous créez un webhook dans Zapier ou Make, vous obtenez une URL qui ressemble à ça :
https://hooks.zapier.com/hooks/catch/123456/abcdef/
Cette URL est :
- ✅ Facile à utiliser (c'est le but)
- ❌ Accessible par QUICONQUE connaît l'URL
- ❌ Sans authentification par défaut
- ❌ Sans validation des données entrantes
- ❌ Sans rate limiting
Traduction : Si quelqu'un devine ou découvre cette URL, il peut déclencher votre automatisation autant de fois qu'il veut, avec n'importe quelles données.
Les 5 erreurs critiques à corriger
Webhook sans secret partagé
Le problème : Votre webhook Zapier/Make accepte toutes les requêtes sans vérifier leur origine.
Impact :
- N'importe qui peut déclencher votre automation
- Injection de données malveillantes dans votre CRM
- Spam de vos clients avec des emails automatisés
- Factures cloud explosives (si vous payez au volume)
La solution :
Pour Zapier :
- Dans votre Zap, ajoutez une étape "Filter" juste après le webhook
- Vérifiez qu'un header spécifique est présent (ex:
X-Secret-Key) - Comparez sa valeur avec un secret que vous seul connaissez
- Si le header ne correspond pas → arrêtez le Zap
// Dans votre requête vers Zapier, ajoutez :
Headers: {
"X-Secret-Key": "votre-secret-ultra-long-et-aleatoire-123"
}
// Dans Zapier Filter :
Only continue if: Headers X-Secret-Key == votre-secret-ultra-long-et-aleatoire-123
Pour Make :
- Utilisez le module "Webhook" avec l'option "Data structure"
- Ajoutez un champ obligatoire "secret" ou "api_key"
- Juste après le webhook, ajoutez un module "Router"
- Créez une condition : si secret ≠ votre_valeur → Stop
✅ Bonne pratique
Générez un secret aléatoire de 32+ caractères avec un outil comme openssl rand -hex 32. Ne réutilisez JAMAIS le même secret pour plusieurs webhooks.
Pas de validation des données entrantes
Le problème : Vous acceptez n'importe quelle donnée envoyée à votre webhook et vous l'injectez directement dans votre CRM, base de données ou service externe.
Impact :
- Corruption de votre base de données avec des données malformées
- Injection SQL si vous envoyez vers une base de données
- Erreurs en cascade qui bloquent toute votre automatisation
- Données personnelles fuitées si un attaquant injecte du code malveillant
La solution :
- Ajoutez TOUJOURS une étape de validation juste après le webhook
- Vérifiez le format de chaque champ important (email, téléphone, URL)
- Utilisez des filtres pour rejeter les données invalides
- Sanitizez les champs texte (retirez les caractères dangereux)
💡 Exemple de validation dans Zapier
Ajoutez un "Filter" avec ces conditions :
- Email contains "@" AND Email contains "."
- Phone matches pattern "[0-9]{10}"
- Name length is greater than 2
Si une seule condition échoue → le Zap s'arrête et ne pollue pas votre système.
Webhook URL exposée publiquement
Le problème : Votre URL de webhook est visible dans le code source de votre site, dans des emails, ou dans des repos GitHub publics.
Impact : Découverte facile par des robots qui scannent Internet 24/7 à la recherche de webhooks exposés.
Où vos webhooks fuient le plus souvent :
- Dans le code JavaScript de votre landing page (visible via "Inspecter l'élément")
- Dans des repos GitHub publics
- Dans des emails HTML (source visible)
- Dans des fichiers de configuration non gitignorés
- Dans la documentation interne partagée publiquement par erreur
La solution :
- Ne JAMAIS mettre l'URL webhook en dur dans du code public
- Utilisez une API intermédiaire qui fait la vraie requête côté serveur
- Si impossible, ajoutez au minimum un secret dans les headers (voir erreur #1)
- Auditez régulièrement GitHub pour "hooks.zapier.com" ou "hook.make.com"
⚠️ Comment vérifier si votre webhook a fuité ?
Cherchez dans Google : site:github.com "hooks.zapier.com" votre-entreprise
Si vous trouvez des résultats → votre webhook est public → CHANGEZ-LE immédiatement.
Aucun rate limiting
Le problème : Un attaquant (ou même un bug) peut appeler votre webhook des milliers de fois par minute.
Impact :
- Facture Zapier/Make qui explose (vous payez par exécution)
- Épuisement de vos quotas API externes (OpenAI, SendGrid, Stripe...)
- Saturation de votre CRM ou base de données
- Déni de service sur vos services dépendants
La solution :
Option 1 - Via Zapier/Make (limité) :
- Zapier : Utilisez l'option "Delay" pour espacer les exécutions
- Make : Configurez "Scenario scheduling" pour limiter la fréquence
Limite : Ces options ne bloquent pas vraiment les abus, elles ralentissent juste votre workflow.
Option 2 - Via un middleware (recommandé) :
- Créez une fonction serverless (Cloudflare Workers, Vercel, AWS Lambda)
- Cette fonction reçoit les requêtes et implémente un vrai rate limiting
- Si le rate limit est respecté → elle appelle votre webhook Zapier/Make
- Sinon → elle renvoie une erreur 429
✅ Rate limit recommandé
Pour un usage légitime, 10 requêtes par minute par IP est généralement suffisant. Adaptez selon votre cas d'usage réel.
Logs contenant des données sensibles
Le problème : Zapier et Make loguent par défaut toutes les données qui passent dans vos workflows. Si vous manipulez des données sensibles (mots de passe, numéros de carte, infos médicales), elles sont stockées en clair dans l'historique.
Impact :
- Non-conformité RGPD (les logs sont stockés aux USA)
- Exposition en cas de compromission de votre compte Zapier/Make
- Risque si un employé quitte l'entreprise avec l'accès
La solution :
- Utilisez l'étape "Formatter" pour supprimer les champs sensibles AVANT tout traitement
- Dans Zapier : activer "Storage by Zapier" en mode chiffré
- Dans Make : utiliser des variables temporaires qui ne sont pas loguées
- Configurez la rétention des logs au minimum (7 jours max)
⚠️ RGPD et webhooks
Si vous traitez des données personnelles de citoyens européens, vous DEVEZ :
- Documenter où passent les données (DPA avec Zapier/Make)
- Limiter la durée de rétention des logs
- Permettre la suppression des données (droit à l'oubli)
- Chiffrer les données sensibles avant envoi au webhook
Checklist de sécurité : Vos webhooks sont-ils protégés ?
🔒 10 points à vérifier immédiatement
- Tous mes webhooks vérifient un secret partagé (header ou query param)
- Je valide le format des données entrantes (email, phone, etc.)
- Mes URLs de webhook ne sont PAS dans mon code public (GitHub, site web)
- J'ai cherché sur Google si mes webhooks ont fuité publiquement
- J'ai un rate limiting en place (Cloudflare, middleware, ou autre)
- Je supprime les données sensibles des logs (ou je les chiffre)
- Mes webhooks s'arrêtent immédiatement si la validation échoue
- Je n'utilise PAS le même secret pour plusieurs webhooks
- J'ai configuré des alertes sur les exécutions anormales (volume élevé)
- Je révise mes webhooks tous les 3 mois pour supprimer ceux qui ne servent plus
✅ Score de sécurité
8-10 points : Excellente sécurité, vos webhooks sont bien protégés.
5-7 points : Base correcte, mais il reste des failles importantes à corriger.
0-4 points : Risque critique. Vos webhooks sont vulnérables, agissez aujourd'hui.
Architecture sécurisée recommandée
Voici l'architecture que nous recommandons pour les agences manipulant des données clients sensibles :
[Formulaire Web]
↓
[Cloudflare Worker avec rate limiting + authentification]
↓ (vérifie le secret + valide les données)
[Webhook Zapier/Make]
↓ (supprime les champs sensibles)
[CRM / Base de données]
Avantages de cette architecture :
- Le webhook Zapier/Make n'est jamais exposé publiquement
- Rate limiting efficace au niveau de Cloudflare
- Validation des données AVANT qu'elles n'atteignent vos systèmes
- Chiffrement possible des données sensibles
- Logs minimaux (Cloudflare peut log sans les données)
Que faire si vous découvrez une faille ?
Si en lisant ce guide vous réalisez que vos webhooks sont vulnérables :
- Audit immédiat : Listez TOUS vos webhooks actifs (Zapier, Make, n8n...)
- Priorisez : Identifiez ceux qui manipulent des
update guide_webhooks_zapier - Priorisez : Identifiez ceux qui manipulent des
- Priorisez : Identifiez ceux qui manipulent des données sensibles
- Ajoutez l'authentification : Commencez par les webhooks critiques
- Changez les URLs : Si un webhook a fuité publiquement, créez-en un nouveau
- Auditez les logs : Vérifiez si des requêtes suspectes ont été faites récemment
- Documentez : Créez une documentation interne sur vos webhooks et leurs secrets
Conclusion : 10 minutes pour sécuriser vos webhooks
Sécuriser vos webhooks Zapier et Make ne nécessite pas de compétences techniques avancées. La plupart des corrections listées dans ce guide peuvent être faites en moins de 10 minutes par webhook.
Action immédiate :
- Imprimez la checklist de 10 points
- Auditez vos 3 webhooks les plus critiques
- Ajoutez au minimum un secret partagé sur chacun
- Testez avec Postman pour vérifier que ça fonctionne
Vos webhooks sont la porte d'entrée de vos automatisations. Si cette porte est ouverte, tout votre système est vulnérable.
Besoin d'un audit complet de vos automatisations ?
Nous auditons tous vos webhooks (Zapier, Make, n8n) et vous donnons un rapport détaillé avec les vulnérabilités détectées et leur criticité. Audit en 48h.
Demander un audit webhooks📚 Articles connexes
Ces guides pourraient aussi vous intéresser :