Zéro soumission enregistrée dans HubSpot pendant trois jours, sur un site qui recevait habituellement une quinzaine de demandes de contact par semaine. Aucune erreur signalée par les visiteurs, aucun message d’échec affiché à l’écran : le formulaire semblait fonctionner normalement, le bouton d’envoi réagissait, mais rien n’arrivait jamais côté HubSpot.
Ce silence complet, sans le moindre message d’erreur visible, est la signature typique d’un pare-feu applicatif (WAF) ajouté récemment au serveur qui bloque, sans le signaler, la requête AJAX envoyée par le formulaire HubSpot vers son domaine de soumission. Le blocage se fait au niveau réseau ou applicatif, avant même que le navigateur ne reçoive une réponse claire à afficher.
Pourquoi le WAF bloque une requête légitime
Un formulaire HubSpot embarqué sur un site WordPress soumet ses données via une requête AJAX vers l’API de formulaires de HubSpot, généralement sur un domaine du type forms.hubspot.com ou forms.hsforms.com. Un pare-feu applicatif configuré avec des règles génériques anti-injection ou anti-bot peut interpréter certains paramètres envoyés par ce formulaire, notamment les identifiants de suivi HubSpot longs et composés de caractères qui ressemblent à des tentatives d’injection, comme une requête suspecte à bloquer.
Ce n’est pas un défaut de configuration du formulaire HubSpot lui-même, qui fonctionne normalement sans le WAF : c’est bien la règle de filtrage ajoutée au niveau du serveur ou du CDN qui intercepte la requête avant qu’elle n’atteigne sa destination.
Diagnostiquer sans accès aux journaux du WAF
Le diagnostic commence dans la console développeur du navigateur, onglet réseau, lors d’une tentative de soumission du formulaire. Une requête qui retourne un code 403 ou qui reste bloquée sans réponse, sur le domaine de soumission HubSpot, confirme l’origine du problème.
# Onglet Réseau du navigateur, lors de l'envoi du formulaire
# POST https://forms.hsforms.com/submissions/v3/...
# Statut : 403 Forbidden
Si l’accès aux journaux du pare-feu applicatif est possible côté hébergeur ou CDN, la recherche par adresse IP source ou par identifiant de règle déclenchée confirme précisément quelle règle a bloqué la requête, information précieuse pour cibler l’assouplissement à apporter.
Assouplir sans désactiver
La tentation de désactiver entièrement le pare-feu applicatif pour résoudre le problème dans l’urgence doit être écartée : cela rouvre le site à l’ensemble des menaces que le WAF était censé filtrer. La bonne approche consiste à créer une exception ciblée, limitée au domaine et au chemin exacts utilisés par HubSpot pour la soumission de formulaires.
# Exemple de règle d'exception, syntaxe générique selon le WAF utilisé
if (req.http.referer ~ "monsite\.fr" &&
req.url ~ "^/submissions/v3/") {
set req.waf.bypass = "hubspot-forms";
}
Selon le pare-feu applicatif utilisé (Cloudflare, un module nginx dédié, ou une solution propriétaire de l’hébergeur), la syntaxe exacte diffère, mais le principe reste identique : autoriser explicitement le chemin de soumission HubSpot plutôt que d’assouplir des règles génériques qui affaibliraient la protection sur l’ensemble du site.
Vérifier après correctif
- Soumettre un formulaire de test avec une adresse e-mail dédiée aux tests, jamais avec des données d’un vrai visiteur
- Confirmer la réception côté HubSpot dans les minutes qui suivent, pas seulement l’absence d’erreur côté navigateur
- Surveiller le volume de soumissions sur la semaine suivant le correctif, pour confirmer un retour au niveau habituel
Un WAF nouvellement installé doit toujours être suivi d’une phase de test actif de tous les formulaires tiers du site, pas seulement du formulaire de contact natif WordPress. Les intégrations externes sont les premières victimes silencieuses d’un pare-feu trop générique.
En résumé
Un formulaire HubSpot qui cesse silencieusement de transmettre ses soumissions, sans erreur visible, pointe presque systématiquement vers un pare-feu applicatif récemment durci qui bloque la requête AJAX de soumission avant qu’elle n’atteigne HubSpot. Le diagnostic passe par la console réseau du navigateur, puis par une exception ciblée sur le domaine et le chemin exacts de soumission, jamais par une désactivation complète du WAF qui exposerait de nouveau le site aux menaces qu’il était censé filtrer.
