Comment sécuriser un formulaire web (spam, injections, RGPD)
Un formulaire web mal sécurisé expose à trois risques distincts : le spam automatisé qui pollue la boîte mail, les injections de code qui compromettent la base de données, et le non-respect du RGPD sur la collecte de données personnelles. Ces trois risques se traitent avec des mesures différentes et complémentaires, aucune ne remplace les autres.
Le vrai problème : un formulaire est une porte ouverte sur le serveur
Contrairement à une page de contenu statique, un formulaire accepte une saisie extérieure et la transmet au serveur pour traitement (envoi d'email, enregistrement en base de données). C'est précisément cette interaction qui en fait une cible privilégiée : chaque champ de saisie est un point d'entrée potentiel pour un contenu malveillant, qu'il s'agisse d'un simple message de spam ou d'une tentative d'exploitation plus poussée.
Les robots qui scannent le web ne ciblent pas des sites en particulier, ils testent systématiquement tous les formulaires qu'ils trouvent, à la recherche d'une faille exploitable. Un formulaire de contact laissé sans protection reçoit généralement du spam en quelques jours, parfois quelques heures, après sa mise en ligne.
Se protéger du spam automatisé
- Ajouter un champ honeypot : un champ invisible pour un humain (masqué en CSS) mais rempli automatiquement par les robots, permettant de rejeter silencieusement leur soumission sans capter d'énergie sur un captcha.
- Intégrer un captcha (reCAPTCHA, hCaptcha ou équivalent) pour les formulaires les plus exposés, en privilégiant les versions récentes qui n'imposent pas de test visuel systématique aux visiteurs légitimes.
- Limiter la fréquence de soumission depuis une même adresse IP, pour bloquer les envois massifs automatisés.
- Vérifier le format des champs (email valide, numéro de téléphone plausible) avant d'accepter la soumission.
- Filtrer les liens et mots-clés suspects dans le contenu du message, technique complémentaire mais jamais suffisante seule.
Éviter les injections de code
Une injection survient lorsqu'un attaquant insère du code exécutable dans un champ de formulaire prévu pour du texte simple, dans le but de manipuler la base de données (injection SQL) ou d'exécuter du code dans le navigateur d'autres visiteurs (injection XSS). La parade tient en deux principes non négociables :
- Toujours valider et filtrer les données côté serveur, jamais uniquement côté navigateur : une validation côté navigateur peut être contournée facilement par un attaquant qui n'utilise pas le formulaire tel qu'affiché.
- Utiliser des requêtes préparées dans le code qui traite les données du formulaire, une pratique standard qui empêche structurellement l'injection SQL, plutôt que de tenter de "nettoyer" manuellement chaque champ.
Sur un CMS comme WordPress, ces protections sont généralement gérées par le cœur du logiciel et les plugins de formulaire reconnus, à condition de les tenir à jour. Un formulaire codé sur mesure sans ces précautions reste la configuration la plus à risque.
Respecter le RGPD sur les données collectées
Tout formulaire qui collecte des données personnelles (nom, email, téléphone) est soumis au RGPD, quelle que soit la taille du site. Les points concrets à vérifier :
- Le formulaire ne demande que les données strictement nécessaires à sa finalité (un formulaire de contact n'a pas besoin de la date de naissance).
- Une mention claire précise pourquoi les données sont collectées et qui les traite.
- Un lien vers la politique de confidentialité est accessible depuis le formulaire.
- Le consentement pour une utilisation secondaire (newsletter par exemple) est distinct et non pré-coché.
- Les données sont conservées pour une durée définie et supprimées au-delà, sauf obligation légale contraire.
Ce qui rend un formulaire vulnérable en pratique
- Absence totale de validation côté serveur, avec une confiance excessive dans la validation du navigateur.
- Champ de fichier joint acceptant n'importe quel format, permettant l'upload de scripts malveillants déguisés en pièce jointe.
- Messages de formulaire affichés en clair sans échappement dans une page d'administration, ouvrant la porte à une injection XSS différée.
- Adresse email de réception exposée en clair dans le code source de la page, facilitant le harvesting par des robots de spam.
Ce qu'il faut retenir
- Un formulaire cumule trois risques distincts (spam, injection, RGPD) qui demandent chacun une réponse spécifique.
- Le honeypot et le captcha réduisent le spam automatisé sans jamais l'éliminer complètement.
- La validation des données doit toujours se faire côté serveur, la validation côté navigateur seule est contournable.
- Les requêtes préparées sont la protection de référence contre les injections SQL, pas le filtrage manuel de chaque champ.
- La conformité RGPD impose de ne collecter que les données nécessaires, avec une finalité claire et une durée de conservation définie.
Questions fréquentes
Un captcha suffit-il à protéger un formulaire du spam ? Il réduit fortement le spam automatisé sans l'éliminer totalement. Combiné à un honeypot et à une validation côté serveur, il couvre l'essentiel des cas pour un formulaire standard.
Qu'est-ce qu'une injection SQL sur un formulaire ? Une technique où un attaquant insère du code dans un champ pour manipuler la base de données. Elle s'évite en validant systématiquement les données côté serveur et en utilisant des requêtes préparées.
Le RGPD impose-t-il un accord explicite pour chaque formulaire ? Il impose un consentement clair et informé, avec une finalité précisée. Cela ne signifie pas une case à cocher pour chaque champ, mais le visiteur doit savoir pourquoi ses données sont collectées.
Faut-il chiffrer les données envoyées par un formulaire ? Le HTTPS chiffre déjà le transport, ce qui couvre l'essentiel pour un formulaire standard. Un chiffrement supplémentaire au stockage se justifie surtout pour des données sensibles.
En résumé
Sécuriser un formulaire web demande de traiter séparément le spam, les injections de code et la conformité RGPD, plutôt que de compter sur une seule protection pour couvrir les trois. Les bases (honeypot, validation côté serveur, collecte minimale de données) sont accessibles sans expertise poussée et suffisent pour la majorité des formulaires de contact professionnels. La formule site web par abonnement VeryAppi intègre des formulaires sécurisés et conformes dès la mise en ligne.
Questions fréquentes
›Un captcha suffit-il à protéger un formulaire du spam ?
Un captcha réduit fortement le spam automatisé mais ne l'élimine pas totalement, surtout face à des services de résolution manuelle bon marché. Combiné à un champ honeypot et à une validation côté serveur, il couvre l'essentiel des cas pour un formulaire de contact standard.
›Qu'est-ce qu'une injection SQL sur un formulaire ?
C'est une technique où un attaquant insère du code dans un champ de formulaire (au lieu d'une réponse normale) pour manipuler la base de données du site : extraire des données, les modifier ou les supprimer. Elle s'évite en validant et en filtrant systématiquement les données saisies côté serveur, jamais uniquement côté navigateur.
›Le RGPD impose-t-il un accord explicite pour chaque formulaire ?
Le RGPD impose un consentement clair et informé pour toute collecte de données personnelles, avec une finalité précisée. Cela ne signifie pas systématiquement une case à cocher séparée pour chaque champ, mais le visiteur doit savoir pourquoi ses données sont collectées et pouvoir s'y opposer facilement.
›Faut-il chiffrer les données envoyées par un formulaire ?
Le HTTPS chiffre déjà le transport des données entre le navigateur et le serveur, ce qui couvre l'essentiel pour un formulaire standard. Un chiffrement supplémentaire au stockage se justifie pour des données sensibles (santé, données bancaires), rarement pour un simple formulaire de contact.