Formulaires de contact WordPress : une liste de contrôle de sécurité

La plupart des sites WordPress utilisent l’un d’une poignée de plugins de formulaire : Contact Form 7, WPForms, Gravity Forms, Ninja Forms, Fluent Forms et quelques autres. Chacun d’eux peut être exploité de manière sécurisée ou laissé grand ouvert. La différence réside rarement dans le plugin lui-même, mais dans ses réglages, les extensions qui l’entourent, la manière dont les e-mails quittent le serveur et ce qu’il advient des messages une fois arrivés.

• Maintenez à jour le plugin de formulaire et chaque extension, et supprimez celles que vous n’utilisez plus.
• Activez l’anti-spam propre au plugin – honeypot, intégration CAPTCHA, Akismet le cas échéant – et vérifiez qu’il fonctionne réellement.
• Envoyez les notifications via un SMTP authentifié depuis une adresse de votre propre domaine.
• Limitez les téléversements par type et par taille, et empêchez que les fichiers téléversés puissent être listés ou parcourus publiquement.
• Tenez l’adresse e-mail du destinataire hors de la page et de son code source.
• N’enregistrez que les entrées dont vous avez besoin, et seulement aussi longtemps que nécessaire.
• Effectuez un court contrôle après chaque mise à jour de WordPress, du thème ou de tout plugin.

Mises à jour : le plugin de formulaire et tout ce qui l’entoure

Les plugins de formulaire sont des cibles prisées, car ils acceptent des saisies de n’importe qui sur internet. Les correctifs de sécurité arrivent sous forme de mises à jour ordinaires ; mettez donc à jour rapidement – et pas seulement le plugin principal. Les extensions pour les paiements, les téléversements, les connexions CRM, la logique conditionnelle ou des fournisseurs de CAPTCHA supplémentaires sont du code distinct, avec ses propres vulnérabilités. Il en va de même des plugins installés un jour pour un test puis oubliés. Les désactiver ne suffit pas : les plugins désactivés restent sur le serveur, et leurs fichiers peuvent dans certains cas être atteints directement. Si vous ne l’utilisez pas, supprimez-le.

Anti-spam : l’activer, puis prouver qu’il fonctionne

La plupart des plugins de formulaire disposent de leurs propres options anti-spam ou s’intègrent à des services externes : un champ honeypot que les robots remplissent et que les humains ne voient jamais, des CAPTCHA comme reCAPTCHA, hCaptcha ou Cloudflare Turnstile, et Akismet, qui compare le contenu des messages à une base de données de spam. Les options varient selon le plugin et la version ; vérifiez donc les réglages plutôt que de supposer. Les CAPTCHA externes chargent des scripts d’un tiers, et Akismet envoie le contenu soumis à un service externe – les deux doivent figurer dans votre politique de confidentialité et, selon votre configuration, dans votre gestion du consentement.

Le problème le plus fréquent est une protection activée mais qui ne fonctionne pas. Un CAPTCHA utilisant des clés de test publiques laisse tout passer. Un widget dont le script est bloqué par un plugin de cache ou d’optimisation, ou par une erreur JavaScript, n’arrête rien. Un champ honeypot sans les styles qui le masquent est lu par les lecteurs d’écran et rempli par de vrais visiteurs. Après toute modification, ouvrez donc le formulaire dans une fenêtre de navigation privée, consultez la console du navigateur et le code source de la page, et envoyez un message de test. Si vous souhaitez une protection qui ne dépende pas de Google, le plugin WordPress gratuit formexposed ajoute un honeypot, un contrôle de durée et une preuve de travail, et revérifie le site après les mises à jour de plugins – une option parmi d’autres.

E-mails : comment ils sont envoyés et où ils vont

Par défaut, WordPress confie les e-mails à la fonction mail de PHP du serveur, et chez de nombreux hébergeurs ces messages sont mal authentifiés et finissent en spam – ou disparaissent sans bruit. Envoyez plutôt via un plugin SMTP ou le service de messagerie de votre hébergeur, en utilisant une véritable boîte aux lettres avec nom d’utilisateur et mot de passe et une adresse d’expéditeur sur votre propre domaine, par exemple une adresse forms@ dédiée. Les enregistrements SPF, DKIM et DMARC du domaine doivent couvrir cet expéditeur. Ne placez pas l’adresse du visiteur dans le champ From : ce n’est pas votre domaine, le message ne peut donc pas satisfaire à l’alignement DMARC et, selon la politique du domaine du visiteur, finit en spam ou est rejeté. Indiquez-la en Reply-To, et vous pourrez toujours répondre en un clic.

L’adresse du destinataire a sa place dans les réglages du plugin, pas dans la page. Vérifiez le code source de votre page de contact : un lien mailto à côté du formulaire, ou un champ masqué contenant l’adresse du destinataire, livre cette adresse à tous les robots collecteurs. Dans les formulaires anciens ou développés sur mesure, cela peut être pire – si le serveur fait confiance à un champ destinataire masqué, n’importe qui peut le modifier et utiliser votre formulaire pour envoyer des e-mails à des adresses arbitraires.

Téléversements et entrées enregistrées

Le téléversement de fichiers est la fonction de formulaire la plus risquée ; demandez-vous donc d’abord si vous en avez réellement besoin. Si c’est le cas, n’autorisez que les types que vous attendez vraiment – par exemple PDF et les formats d’image courants – au lieu de bloquer quelques types dangereux, et fixez une limite de taille. Vérifiez où le plugin stocke les téléversements : ils ne doivent pas pouvoir être listés dans un répertoire public et, idéalement, ne doivent pas du tout être accessibles à une adresse devinable. Supprimez-les une fois traités, ou envoyez-les en pièces jointes au lieu de les conserver sur le serveur.

De nombreux plugins de formulaire ou leurs extensions enregistrent chaque envoi dans la base de données WordPress, souvent spam compris. C’est une sauvegarde utile en cas d’échec de l’envoi d’e-mails, mais aussi une pile croissante de données à caractère personnel. En vertu du principe de limitation de la conservation du RGPD (Art. 5(1)(e)), ces données ne devraient pas être conservées plus longtemps que nécessaire. Décidez si vous avez besoin d’entrées enregistrées, de quels champs et pour combien de temps, puis utilisez le réglage de suppression automatique du plugin s’il en existe un, ou supprimez régulièrement les anciennes entrées. Les sauvegardes de la base de données contiennent les mêmes données.

Après chaque mise à jour

1. 1Ouvrez la page de contact dans une fenêtre de navigation privée : le formulaire et son élément anti-spam s’affichent correctement, et la console du navigateur ne montre aucune erreur.
2. 2Affichez le code source de la page : le champ honeypot et le script du CAPTCHA sont toujours présents, et l’adresse du destinataire ne l’est pas.
3. 3Envoyez un message de test : il arrive dans la boîte de réception, pas dans le spam, et les en-têtes indiquent que SPF, DKIM et DMARC sont validés.
4. 4Vérifiez les réglages qui comptent : destinataire, adresse d’expéditeur, types et tailles de téléversement autorisés, durée de conservation des entrées.
5. 5Vérifiez que le lien vers la politique de confidentialité et l’éventuel texte de consentement sont toujours affichés au niveau du formulaire.
6. 6Notez la date et ce que vous avez vérifié, afin de savoir quand le formulaire a fonctionné pour la dernière fois de manière prouvée.

Une fois devenu une routine, cela prend peu de temps et permet de repérer précisément les défaillances silencieuses qui passent sinon inaperçues pendant des semaines. Pour un regard extérieur, une vérification gratuite sur formexposed.com examine les pages de formulaire publiques d’un site sans rien soumettre et indique si la protection attendue est en place et configurée efficacement – sans compte.