L'attaque que personne ne voit arrive par le formulaire de contact de ton site

Tout le monde protège le login. Personne ne regarde le formulaire de contact. Et pourtant il accepte l'entrée de n'importe qui, sans authentification, sans friction, souvent sans même une limite d'envois.

C'est cette asymétrie que l'attaquant recherche. Une zone de texte qui parle à ton serveur de messagerie, à ta base de données, ou à un webhook interne. Toi tu vois un champ « message ». Lui voit une ligne de commande.

Pourquoi cette cible est si tentante

Un formulaire de contact réunit trois propriétés rares au même endroit. Il accepte une entrée non fiable. Il exécute de la logique sur le serveur. Et il n'est presque jamais audité. Le développeur a vérifié que le message arrive dans la boîte mail. Il s'est arrêté là.

Le problème, c'est que « le message arrive dans la boîte mail » cache tout un parcours. Le texte de l'utilisateur est assemblé dans un en-tête SMTP, concaténé dans une requête, ou envoyé vers un service tiers. Chacune de ces frontières est une occasion d'injection.

Injection d'en-têtes d'email

Le cas classique s'appelle l'email header injection. Si tu prends le champ « objet » ou « expéditeur » et que tu le colles directement dans l'en-tête du message, un attaquant écrit un saut de ligne et ajoute ses propres en-têtes. Un Cci vers mille adresses, par exemple.

D'un coup ton serveur envoie du spam. Pas en ton nom par hasard, mais littéralement via ton infrastructure, avec ton IP et ton domaine. Le résultat est prévisible : les grands fournisseurs marquent ton domaine comme source de spam et ton email professionnel n'arrive plus nulle part.

Le texte qui devient du code

Ensuite il y a les scénarios pires. Si tu enregistres le message dans une base de données sans paramétrer la requête, tu ouvres la porte à l'injection SQL. Si tu affiches le message dans un panneau d'admin sans échapper le HTML, l'attaquant plante un script qui s'exécute dans le navigateur de ton équipe quand elle ouvre le lead. C'est du XSS stocké, et c'est l'un des vecteurs les plus sous-estimés qui existent.

Regarde le schéma. Dans aucun de ces cas l'attaquant n'a « pénétré » quoi que ce soit. Il a utilisé le formulaire exactement comme il est conçu pour l'être. La vulnérabilité n'est pas une faille exotique. C'est l'absence d'une règle simple : ne fais jamais confiance à ce qui entre.

Quoi faire, par ordre de priorité

Tu n'as besoin ni d'un WAF ni d'un consultant en sécurité pour fermer 90 % de tout ça. Tu as besoin de discipline sur quatre points.

• Valide côté serveur, jamais seulement dans le navigateur. La validation front-end est un confort pour l'utilisateur, pas une sécurité. L'attaquant n'utilise pas ton formulaire, il fait un POST direct vers l'endpoint.
• Échappe à la sortie, toujours. Pour enregistrer en base de données, utilise des requêtes paramétrées. Pour afficher dans un panneau, échappe le HTML. Traite chaque message comme hostile jusqu'à preuve du contraire.
• Rejette les sauts de ligne dans les champs d'en-tête. L'objet, le nom et l'email n'ont aucune raison de contenir \r ou \n. Filtre-les avant de toucher au SMTP.
• Limite le débit d'envois et ajoute un défi invisible. Le rate limiting par IP et un honeypot ou hCaptcha arrêtent les bots automatiques sans gâcher l'expérience de qui est humain.

Et le côté que presque tout le monde oublie

Un formulaire de contact collecte des données personnelles. Nom, email, souvent le téléphone et le contenu du message. Ça te place à l'intérieur du RGPD, que ça te plaise ou non. Il te faut une base légale pour traiter ces données, et le consentement doit être éclairé.

En pratique cela signifie trois choses concrètes. Une note de confidentialité claire liée au formulaire. Une base légale définie, typiquement l'intérêt légitime de l'article 6 ou le consentement explicite. Et une politique de conservation, parce que garder des leads pour toujours n'est pas une stratégie, c'est une responsabilité qui s'accumule. Si on te vole la base de données de leads, le problème cesse d'être technique et devient réglementaire.

La sécurité d'un formulaire, ce n'est pas un pare-feu coûteux. C'est refuser de faire confiance au texte qu'un inconnu a écrit.— Krivar Diário

La morale est ennuyeuse et c'est pour ça qu'elle marche. L'attaque que personne ne voit arrive par la porte que personne ne regarde. Traite ton formulaire de contact avec le même respect que tu accordes au login, et la plupart de ces problèmes n'arriveront jamais.