Votre formulaire de contact est une porte d'entrée : comment le sécuriser

Un formulaire est le seul endroit de votre site où n'importe qui peut taper ce qu'il veut et où le site doit l'accepter. Le plus souvent, c'est un client qui demande un prix ou une date. Parfois, c'est un robot qui remplit des formulaires de site en site, toute la journée. Et parfois, c'est une personne qui teste ce que le formulaire avale sans broncher.

C'est pourquoi les formulaires de contact, de commande et de prise de rendez-vous font partie des premières choses qu'un attaquant regarde. Voici les risques, comment les reconnaître et ce qu'il faut demander à la personne qui s'occupe de votre site.

Un flot de spam, c'est plus qu'une boîte de réception en désordre

Le problème le plus courant est aussi le moins dangereux, du moins en apparence. Des robots envoient par votre formulaire des centaines de messages remplis de publicités et de liens. La boîte se remplit, et la vraie demande d'un client se perd quelque part au milieu.

Cela se complique quand le formulaire envoie une confirmation ou une copie du message à l'adresse saisie. Le robot saisit alors des adresses d'inconnus, et votre serveur leur envoie des e-mails au nom de votre domaine. La réputation de votre domaine en souffre vite : les messageries le traitent comme une source de spam, et vos vrais e-mails, factures comprises, atterrissent dans les courriers indésirables de vos clients. Votre hébergeur peut aussi bloquer l'envoi de mails sur tout le compte.

Si votre formulaire propose « m'envoyer une copie », demandez-vous si vous en avez vraiment besoin.

Trois attaques, une phrase chacune

Les noms sont alarmants, mais le principe est simple. Chacune fonctionne parce que le formulaire fait confiance à ce que quelqu'un a tapé.

Injection d'en-têtes d'e-mail : quelqu'un saisit des sauts de ligne et des adresses supplémentaires dans le champ e-mail ou objet, et un formulaire mal écrit envoie alors depuis votre serveur des messages à toutes les adresses de son choix.

Injection SQL : quelqu'un saisit un fragment de commande de base de données dans un champ, et un formulaire qui transmet le texte tel quel à la base l'exécute, ce qui peut révéler ou modifier les données qui y sont stockées.

Cross-site scripting (XSS) : quelqu'un saisit un morceau de script à la place de son nom, et quand vous ouvrez ce message dans l'espace d'administration, le script s'exécute dans votre navigateur avec vos droits d'administrateur.

Votre développeur vous protège des trois : les données saisies sont vérifiées et filtrées avant d'arriver dans un e-mail ou dans la base, et elles s'affichent dans l'administration d'une manière qui ne peut rien exécuter. Les extensions populaires et à jour le font par défaut. Le risque est plus grand avec un formulaire écrit à la main il y a quelques années, que personne n'a regardé depuis. Demandez donc directement si votre formulaire vient d'une extension ou s'il a été écrit sur mesure, et dans ce cas qui l'a relu en dernier et quand.

Les fichiers envoyés par les clients

Beaucoup de formulaires permettent de joindre un fichier : un CV, la photo d'un dégât, un document scanné, un plan pour un devis. C'est pratique, et c'est aussi la partie la plus risquée d'un formulaire.

Le plus gros danger est un fichier qui se fait passer pour une image alors que c'est un programme, par exemple nommé facture.jpg.php. Si le serveur l'accepte et le laisse s'exécuter, l'attaquant prend le contrôle du site. Demandez donc à votre développeur de confirmer que :

• le formulaire n'accepte que des types de fichiers précis, comme PDF, JPG et PNG, et vérifie le contenu du fichier, pas seulement la fin de son nom,
• il existe une limite de taille,
• les fichiers reçus vont dans un dossier où le serveur n'exécute rien, de préférence en dehors de la partie publique du site,
• les fichiers enregistrés reçoivent des noms nouveaux et aléatoires.

De votre côté, il reste la prudence à l'ouverture. Un document Word qui demande d'activer les macros dès son ouverture est un grand classique de l'infection d'ordinateur. Rappelez-vous aussi que des CV et des photos envoyés à une clinique sont des données personnelles, parfois sensibles : ne les conservez pas plus longtemps que nécessaire.

Captcha, pot de miel et limitation du débit

Il y a trois moyens de s'occuper des robots, et ils fonctionnent mieux ensemble.

Un pot de miel est un champ supplémentaire du formulaire que les personnes ne voient pas. Les robots remplissent tous les champs : si celui-là contient quelque chose, le formulaire écarte le message sans rien dire. Les clients ne remarquent rien, et les robots les plus simples disparaissent.

Un captcha distingue les personnes des robots. Les plus récents, comme Google reCAPTCHA v3, Cloudflare Turnstile ou hCaptcha, travaillent surtout en arrière-plan, sans lettres à recopier ni feux de circulation à cliquer. Gardez en tête qu'ils transmettent des informations sur vos visiteurs à une autre entreprise : votre politique de confidentialité doit donc les mentionner.

La limitation du débit plafonne le nombre de messages envoyables depuis une même adresse en peu de temps. Un vrai client a très peu de chances de s'en apercevoir, mais elle arrête les vagues de spam et les tests automatisés du formulaire. Elle se règle sur le serveur ou dans un service de pare-feu comme Cloudflare.

Un pot de miel avec une limitation du débit suffit en général pour commencer. Ajoutez un captcha si du spam passe encore.

Où atterrissent les messages et qui peut les lire

Un message de votre formulaire peut finir à deux endroits : dans une boîte de réception et dans la base de données du site. Certaines extensions se contentent d'envoyer un e-mail. D'autres enregistrent aussi chaque envoi dans l'administration, en général sous un menu intitulé « Entrées » ou « Soumissions ». Connectez-vous et regardez ce qui s'applique chez vous.

Répondez ensuite à quelques questions :

1. Qui a accès à la boîte qui reçoit les messages ? Quelqu'un l'a-t-il redirigée vers un Gmail personnel avant de partir ?
2. Qui a un compte administrateur ? Chacun d'eux peut lire tous les messages enregistrés.
3. Combien de temps les messages sont-ils conservés ? Certaines extensions permettent de supprimer automatiquement les anciennes entrées.
4. La page qui contient le formulaire fonctionne-t-elle en HTTPS, avec le cadenas ?

Chaque message contenant un nom, une adresse e-mail et un numéro de téléphone est une donnée personnelle dont vous êtes responsable. Ce que cela implique au regard du RGPD est expliqué dans l'article sur le RGPD et la sécurité du site.

Une extension à jour, et une seule au lieu de trois

Les extensions de formulaires font partie des plus installées, et les attaquants les surveillent de près. On y trouve et corrige régulièrement des failles : la mise à jour de votre extension de formulaire ne doit donc pas attendre des semaines dans la file.

Profitez-en pour compter combien d'extensions de formulaires sont installées. Il y en a parfois trois : une de la première version du site, une de la refonte et une qui sert vraiment. Supprimez celles que vous n'utilisez pas, au lieu de simplement les désactiver, car leurs fichiers restent sur le serveur.

Et une habitude qui ne coûte rien : une fois par mois, envoyez un message de test par votre propre formulaire. Un formulaire peut cesser de fonctionner sans prévenir, et le client pense alors que vous l'ignorez, alors que vous ne savez même pas qu'il a écrit.