Base

Côté client

• Utiliser les validations côté client
• Éviter l’injection HTML (XSS) : toujours échapper les contenus dynamiques
• Limiter les informations exposées : pas de données sensibles dans le DOM, les URL ou le localStorage.

Côté serveur

• Validation des entrées : Toujours nettoyer et filtrer les données entrantes.

• Prévention des injections SQL : Utiliser des requêtes préparées.

• Authentification sécurisée : Hashage des mots de passe, jamais de mot de passe en clair

• Limiter les messages d’erreur : Pas de détails en production.

Sécurisation de formulaire

Un formulaire accessible sans authentification doit être protégé contre un usage abusif par des robots.

Il faut pouvoir distinguer la soumission d'un formulaire par un être humain d'un robot.

Utilisation de Captcha

• requiert une librairie ou une API (exemple: reCaptcha de Google, hCaptcha, FriendlyCaptcha)

• problème accessibilité: lecture difficile des caractères déformés => présence parfois de la possibilité d'écouter la lecture des caractères

• nécessite une opération supplémentaire de l'utilisateur

• protection non fiable dans le temps => nécessité de mettre à jour régulièrement la librairie

Sécurisation sans Captcha

Aucune méthode de sécurisation n'est fiable à 100%, il faut diversifier les précautions comme:

Champ "honeypot"

Ajout d'un champ avec label masqué (par CSS en feuille de style externe !)

Le champ de saisie est un champ factice uniquement destiné à tromper les robots. Il sera masqué visuellement et en le remplissant, le robots destiné à vous spammer se trahira lui-même.

<?php 
    /*fichier contact.php*/    
    (...)
      if (!empty($_POST['info'])) {
        $message .= "Requête refusée : trop d\infos !<br>";
        $valid = false;
      }
    (...)
?>
(...)
    <form method="post" action="<?php echo htmlentities($_SERVER['PHP_SELF']); ?>">
        <label class="info"><span></span><input type="text" name="info" value=""/></label>  
        <label><span>Votre nom d'utilisateur:</span><input type="text" name="newuser" value=""/></label>
        <label><span>Votre adresse courriel:</span><input type="courriel" name="email" value=""/></label>
        <button type="submit" name="buttNewUser">Envoyer</button>
    </form>
(...)

/*fichier style.css*/
(...)
label.info {
    display: none;
}
(...)

Vérification HTTP_REFERER

Vérification de l'adresse qui soumet la requête (attention: dépendance de l'adresse d'hébergement !)

<?php
    /*fichier contact.php*/
    (...)
    function checkOrigin($url){
        $urlSegments = explode("/", $url);
        return (count($urlSegments) > 3 && 
                $urlSegments[2].'/'.$urlSegments[3] === '192.168.128.13/~p150107') ? true : false;
    }
    (...)
    if (!checkOrigin($_SERVER['HTTP_REFERER'])) {
        $message .= "Requête refusée : origine incorrecte !<br>";
        $valid = false;
    }
    (...) 

Filtrage HTML / hyperliens

Vérification de la présence d'hyperlien ou de code HTML dans les champs textes

<?php 
    /*fichier contact.php*/
    (...)
    $data = $_POST['newuser'].$_POST['email'];
    if ($data != strip_tags($data)) {
        $message .= "Requête refusée : texte avec balises !<br>";
        $valid = false;
    }
    (...)

Javascript

• Refuser une soumission moins de 10s après l'affichage du formulaire

• Créer les champs de formulaire à la volée

• Facile à contourner par des robots modernes ou via des outils headless comme Puppeteer

• Injuste pour utilisateurs très rapides ou avec auto-remplissage

CSRF Token

Qu'est-ce qu'une attaque CSRF ?

Une attaque CSRF (Cross-Site Request Forgery), ou falsification de requête inter-sites, consiste à tromper un site web pour qu’il exécute une action à la place d’un utilisateur authentifié, sans son consentement.

Elle exploite deux éléments :

• Le fait que le navigateur envoie automatiquement les cookies de session avec chaque requête.
• L’absence de mécanisme de vérification de l’origine de la requête

*Contre-mesures *

• Utiliser des CSRF Tokens (jetons aléatoires, uniques par formulaire).
• Refuser les requêtes POST sans ce jeton valide.
• Ajouter une vérification d'origine (header Origin ou Referer).
• En complément : limiter la durée des sessions, vérifier les actions sensibles.

Exemples

Formulaire de contact d’un site public

Le pirate intègre un script dans un site tiers qui soumet le formulaire à répétition.

Cela génère du spam, surcharge le serveur ou exécute une injection si le formulaire est mal filtré.

But de l’attaque : exploiter l’ouverture du formulaire (sans authentification) pour saturer ou manipuler le système.

Contre-mesures : Champ honeypot / Temporisation JS / Filtrage HTML

Uilisateur connecté

Un utilisateur est connecté à son compte sur un site de vente en ligne.

• Il visite un site malveillant dans un autre onglet
• Ce site envoie automatiquement une requête POST vers le site marchand, modifiant l’adresse de livraison enregistrée.
• Le site de vente, utilisant les cookies de session, pense que la requête est légitime.
• Lors de la prochaine commande, les produits sont envoyés à l’adresse du pirate.

But de l’attaque : détourner une commande ou provoquer une fraude logistique

Contre-mesure : intégrer un CSRF Token dans tous les formulaires liés aux données sensibles

Tableau comparatif

🛡️ Méthode	✅ Efficacité	♿ Accessibilité	⚙️ Simplicité d'implémentation	Remarques critiques
CAPTCHA	Moyenne à forte	Faible	Moyenne à faible	Dépendance à un tiers, accessibilité médiocre
Champ "honeypot"	Moyenne	Excellente	Très simple	Contournable par bots avancés, mais très utile combiné à d'autres
Vérification HTTP_REFERER	Faible	Excellente	Simple	Facile à falsifier, ne doit pas être utilisé seul
Temps minimum de soumission	Faible à moyenne	Bonne	Moyenne	Injuste pour les utilisateurs rapides ou avec auto-remplissage
Champs dynamiques JS	Moyenne	Moyenne à bonne	Moyenne	Inefficace si JS désactivé, utile combiné à d’autres techniques
CSRF Token	Forte	Excellente	Moyenne	Indispensable pour les formulaires authentifiés
Filtrage HTML / hyperliens	Moyenne	Excellente	Moyenne	Bonne mesure de base, mais ne protège pas contre les bots

• Aucune méthode n’est parfaite seule : combinaison recommandée
• Accessibilité doit toujours être prise en compte

OWASP

Allez plus loin :

OWASP – Open Worldwide Application Security Project

• Organisation à but non lucratif fondée en 2001.

• Objectif : améliorer la sécurité des logiciels dans le monde entier.

• Fournit des ressources gratuites et ouvertes à tous (développeurs, architectes, enseignants…).

Ressources principales :

• OWASP Top 10 : Classement des 10 risques de sécurité applicative les plus critiques.

• Cheat Sheet Series : Fiches pratiques pour appliquer les bonnes pratiques de sécurité.

• ZAP : Outil gratuit d’analyse de vulnérabilités web (scanner proxy).

• ASVS (Application Security Verification Standard) : Guide d’audit de sécurité logiciel.

• Juice Shop : Application volontairement vulnérable pour l’apprentissage.

Référence officielle >>