Chaque site web d'entreprise possede un formulaire de contact. C'est le moyen le plus simple pour les clients potentiels de vous joindre. C'est aussi, dans de nombreux cas, le moyen le plus simple pour les attaquants d'atteindre votre serveur.
Un formulaire de contact est une interface entre le monde exterieur et votre application web. Il accepte des entrees de n'importe qui sur internet et les transmet a votre serveur pour traitement. Si ces entrees ne sont pas correctement validees et assainies, le formulaire devient un vecteur d'attaque.
Comment les Formulaires Deviennent des Vecteurs d'Attaque
Le probleme fondamental est la confiance. Si votre application fait confiance aux donnees provenant d'un formulaire, un attaquant enverra des donnees qui ne sont ni sures ni bien formatees.
La Validation Cote Client N'Est Pas de la Securite
La validation JavaScript dans le navigateur offre une bonne experience utilisateur mais zero securite. Un attaquant la contourne en desactivant JavaScript ou en envoyant des requetes directement au serveur avec curl ou Burp Suite.
Injection SQL via les Champs du Formulaire
L'injection SQL se produit lorsque l'entree du formulaire est inseree directement dans une requete de base de donnees sans parametrisation. Un attaquant peut lire votre base entiere, modifier des donnees, supprimer des tables, et parfois executer des commandes systeme.
La Solution
Requetes parametrisees (prepared statements). Le parametre est traite comme une donnee, jamais comme du code SQL.
Cross-Site Scripting (XSS) via les Champs d'Entree
Le XSS fonctionne quand les donnees soumises sont affichees sur une page sans encodage. Un attaquant soumet du JavaScript via votre formulaire, et quand un admin visualise la soumission, le script s'execute dans son navigateur, volant sa session.
La Solution
Encodage de sortie. Chaque fois que vous affichez des donnees utilisateur, encodez les caracteres speciaux HTML. Implementez aussi un en-tete Content-Security-Policy (CSP). Voir notre guide sur les vulnerabilites OWASP Top 10.
Vulnerabilites d'Upload de Fichiers
Si la validation d'upload est insuffisante, un attaquant peut uploader un script PHP deguise en image. Techniques de contournement courantes :
- Double extension :
malware.php.jpg - Usurpation MIME : Content-Type en
image/jpegpour un fichier PHP - Injection d'octet nul :
malware.php%00.jpg - Upload de .htaccess : Reconfigurer le serveur pour executer les .jpg comme PHP
La Solution
- Valider le contenu du fichier, pas seulement les extensions
- Stocker les fichiers hors de la racine web
- Renommer avec des noms aleatoires (UUID)
- Utiliser une liste blanche de types autorises
Cross-Site Request Forgery (CSRF)
Le CSRF trompe un utilisateur pour qu'il soumette un formulaire involontairement. La solution : des tokens CSRF uniques dans chaque formulaire et l'attribut SameSite sur les cookies de session.
Injection d'En-tetes Email
Un attaquant injecte des en-tetes email supplementaires via le champ email, transformant votre serveur en relais de spam. Cela entraine le blacklisting de votre serveur mail et la degradation de votre reputation de domaine.
La Solution
Utiliser des bibliotheques email (PHPMailer, Nodemailer) au lieu de fonctions mail() brutes. Supprimer les caracteres de nouvelle ligne de toutes les entrees.
SSRF via les Champs URL
Si votre formulaire accepte des URL, un attaquant peut soumettre des URL pointant vers des ressources internes. Validez, restreignez les protocoles, bloquez les plages IP privees.
Spam et Abus Automatise
CAPTCHA vs. Honeypot
Le CAPTCHA ajoute un defi que les bots ne peuvent pas facilement resoudre. Les champs honeypot sont des champs caches invisibles aux humains mais remplis par les bots. Bonne pratique : utiliser les deux.
Limitation de Debit
Limiter le nombre de soumissions par IP par heure.
Comment Tester Vos Formulaires
Test XSS
Soumettez <script>alert('test')</script> dans chaque champ. Si un popup JavaScript apparait, le formulaire est vulnerable.
Test Injection d'En-tetes Email
Soumettez test@example.com%0ABcc:test2@example.com dans le champ email.
Test SQLi Basique
Soumettez test' OR '1'='1 dans un champ texte. Un message d'erreur mentionnant SQL indique une vulnerabilite potentielle.
Ce sont des tests basiques. Pour une evaluation professionnelle, contactez notre equipe.
Checklist Securite des Formulaires
| Mesure | Prevention | Implementation |
|---|---|---|
| Validation cote serveur | Toutes les injections | Valider type, longueur, format, caracteres |
| Requetes parametrisees | Injection SQL | Prepared statements |
| Encodage de sortie | XSS | Encoder HTML toutes les donnees utilisateur |
| Tokens CSRF | CSRF | Tokens uniques dans chaque formulaire |
| Validation upload | Execution de code | Liste blanche, validation contenu, stockage hors racine |
| Assainissement en-tetes email | Injection en-tetes | Bibliotheques email, suppression newlines |
| Limitation de debit | Spam, brute force | Limiter soumissions par IP |
| CAPTCHA ou honeypot | Spam automatise | reCAPTCHA, hCaptcha ou champ cache |
Pour les en-tetes de securite HTTP, voir notre guide sur les en-tetes de securite indispensables.
Exemples Reels au Tessin
Cas 1 : Une Agence de Recrutement
Upload de CV sans validation serveur. Web shell PHP uploadee. Base de donnees de candidats extraite. Violation de donnees sous nLPD.
Cas 2 : Un Etablissement Hotelier
Formulaire de reservation sans protection CSRF. Enregistrements modifies, emails de confirmation rediriges. Clients arnagues.
Cas 3 : Un Cabinet de Conseil
Injection d'en-tetes email dans le formulaire de contact. Plus de 50 000 spams envoyes via le serveur mail de l'entreprise. Serveur blackliste pendant trois semaines.
Ce Que Vous Devez Faire
- Auditez vos formulaires avec les tests decrits ci-dessus.
- Interrogez votre developpeur : "Les entrees sont-elles validees cote serveur ? Utilisons-nous des requetes parametrisees ? Nos formulaires ont-ils des tokens CSRF ?"
- Implementez les en-tetes de securite. CSP en particulier.
- Obtenez une evaluation professionnelle. Contactez notre equipe pour un audit complet.
Votre formulaire de contact est fait pour vous connecter avec vos clients. Assurez-vous qu'il ne vous connecte pas aussi avec des attaquants.
Vous voulez savoir si votre site est sécurisé ?
Demandez un audit de sécurité gratuit. En 48 heures vous recevez un rapport complet.
Demander un Audit Gratuit