Spam des formulaires : honeypot, rate limiting, Turnstile

Publiez un formulaire, attendez quelques jours, et les bots le trouvent. Comprendre comment ils opèrent rend les défenses évidentes - et explique pourquoi la bonne réponse est une superposition de couches, pas un unique CAPTCHA nucléaire.

Connaître l'ennemi : trois types de spam de formulaire

1. Robots stupides - des scripts qui trouvent chaque <form> sur le web et bombardent l'URL d'action de requêtes POST. Ils remplissent chaque champ qu'ils voient. C'est l'immense majorité du volume.
2. Inondations ciblées - quelqu'un (ou le botnet de quelqu'un) qui martèle spécifiquement votre endpoint, souvent simplement parce qu'il existe.
3. Fermes de spam humaines - de vraies personnes payées pour remplir des formulaires. Rares pour les formulaires de contact ; aucune défense automatisée ne les arrête complètement, et ce n'est pas grave - elles représentent une erreur d'arrondi.

Chaque couche ci-dessous correspond à l'un de ces cas.

Couche 1 : le honeypot (arrête les robots)

Un honeypot est un champ supplémentaire que les humains ne voient jamais - caché via CSS - mais que les robots stupides remplissent consciencieusement parce qu'il est présent dans le markup :

Règle côté serveur : si ce champ arrive non vide, la soumission est du spam. Acceptez-la silencieusement (renvoyez 200) et jetez-la, pour que le bot n'apprenne rien. Cette seule astuce élimine la majeure partie du spam avec zéro friction pour les humains - pas de puzzle, pas de clic, rien.

Les détails qui comptent : donnez-lui un nom tentant (website, phone2), gardez-le hors de l'ordre de tabulation, et marquez-le aria-hidden pour que les lecteurs d'écran l'ignorent - invisible pour l'accessibilité, pas seulement caché visuellement.

Couche 2 : la limitation de débit (arrête les inondations)

Les honeypots n'aident pas quand un bot envoie des POST aux données apparemment valides 500 fois par minute. Les limites de débit par IP et par formulaire, si : un vrai humain ne soumet pas un formulaire de contact dix fois en soixante secondes, donc rien d'utile n'est perdu en limitant le débit. Les limites doivent se situer au niveau de l'endpoint de réception, avant le stockage et les notifications - sinon une inondation remplit quand même votre boîte de réception, même si elle est signalée.

Couche 3 : Turnstile (quand la pression exige un défi)

Quand un formulaire attire des bots plus intelligents - des navigateurs headless qui rendent le CSS et contournent votre honeypot - vous passez à un défi. Cloudflare Turnstile est le choix moderne : il vérifie l'humanité via des signaux du navigateur et se résout généralement de façon invisible, sans les quiz photo de bouches d'incendie. Le flux est standard : un widget sur votre page produit un jeton, le serveur de réception vérifie ce jeton auprès de Cloudflare, et les soumissions sans jeton valide sont rejetées.

Turnstile est la couche à ajouter en cas de besoin, pas de façon préventive - chaque défi, aussi discret soit-il, coûte une fraction de conversion.

À quoi ça ressemble quand c'est le travail de quelqu'un d'autre

Si vous gérez votre propre récepteur de formulaire, vous implémentez les trois couches - et vous devez les maintenir en état de marche indéfiniment. C'est une grande partie de ce à quoi sert un backend de formulaire. Formhook fournit le honeypot, des limites de débit par IP et par formulaire, et une liste CORS par formulaire activée par défaut, sur tous les forfaits y compris le forfait gratuit ; Turnstile est une case à cocher dans les paramètres du formulaire quand vous voulez la couche supplémentaire.

Quelle que soit la voie choisie, la stratégie est la même : défenses invisibles en premier, défis visibles par les humains en dernier, et jamais un CAPTCHA comme premier geste.