Manipulez les grandes failles web — en sécurité — pour comprendre comment elles
fonctionnent et, surtout, comment les corriger.
⚠️ Tout est simulé ou confiné. Aucune attaque réelle. N'expérimentez jamais sur un site sans autorisation : ce serait illégal.
Faille XSS (Cross-Site Scripting)
Un site affiche un commentaire sans l'échapper. Ce que vous tapez est interprété comme du code par le navigateur.
Laissez un commentaire
Zone d'affichage du site (confinée)
Le regard du formateur
En mode vulnérable, le commentaire est inséré tel quel dans la page : la balise
<img onerror> déclenche du JavaScript. Un attaquant peut ainsi voler des
cookies de session, défigurer la page ou rediriger la victime. Ici, le rendu tourne dans
une iframe « sandbox » isolée : le script s'exécute mais ne peut pas toucher la page Cyberini
ni vos cookies.
Le correctif
Échapper systématiquement les sorties (htmlspecialchars() en PHP, textContent
plutôt que innerHTML en JS), et ajouter une CSP (Content-Security-Policy).
Cochez « version corrigée » : le même commentaire s'affiche alors comme du texte inoffensif.
Injection SQL
Un formulaire de connexion construit sa requête en collant directement vos entrées. On peut la détourner.
Connexion (identifiant valide : admin / S3cr3t!)
Requête envoyée à la base
SELECT * FROM users WHERE user='' AND pass=''
Le regard du formateur
Avec admin' -- dans l'identifiant, le -- met le reste de la requête en
commentaire : le mot de passe n'est plus vérifié, on entre en tant qu'admin. Avec
' OR '1'='1, la condition devient toujours vraie. C'est l'une des failles les plus
anciennes… et toujours d'actualité.
Le correctifRequêtes préparées (paramétrées) : les entrées sont traitées comme des données,
jamais comme du code SQL. Cochez la case : l'injection ne fonctionne plus.
Altération de paramètres web
Le prix est envoyé par le navigateur. Si le serveur lui fait confiance, on peut le modifier.
Le regard du formateur
Mettez le prix à 0 puis validez : en mode vulnérable, le serveur encaisse le prix
que vous avez choisi. Le champ pourrait être caché dans la page — un attaquant l'édite via
les outils du navigateur. Règle d'or : ne jamais faire confiance aux données venant du client.
Le correctif
Le serveur doit recalculer le prix à partir de l'identifiant produit, côté serveur, et
ignorer toute valeur de prix transmise. Cochez la case : le prix réel (49 €) s'applique.
Sécurité JavaScript
Une « zone réservée » protégée par un mot de passe vérifié… côté navigateur. Tout est visible.
Accès réservé
Le regard du formateur
Le mot de passe attendu est écrit en clair dans le JavaScript envoyé au navigateur :
n'importe qui peut le lire (« voir le code source »). Toute vérification d'accès ou tout
« secret » côté client est public.
Le correctif
Les contrôles d'accès et les secrets vivent côté serveur. Le client ne reçoit que ce
qu'il a le droit de voir, après authentification serveur.
Autres failles (à explorer)
Failles surtout côté serveur : on les explique ici et certaines sont simulées en mini-labs 100 % navigateur.
IDOR / contrôle d'accès cassé
Changer un identifiant dans une URL pour lire une ressource qui appartient à quelqu'un d'autre.
✅ Vérifier l'autorisation côté serveur pour chaque objet.
mini-démo ci-dessous
CSRF
Forcer la victime, déjà connectée, à exécuter une action à son insu (ex. modifier son e-mail).
✅ Jeton anti-CSRF + SameSite cookies.
mini-démo ci-dessous
Clickjacking
Superposer un cadre invisible : la victime croit cliquer sur un bouton anodin mais agit ailleurs.
✅ En-tête X-Frame-Options / frame-ancestors.
mini-démo ci-dessous
Vol de session
Récupérer le cookie de session (souvent via XSS) pour usurper l'utilisateur connecté.
✅ Cookies HttpOnly, Secure, rotation de session.
démo à venir
Directory traversal
Manipuler un chemin (../../etc/passwd) pour lire des fichiers hors du dossier prévu.
✅ Normaliser/valider les chemins, liste blanche.
démo à venir
XXE
Un parseur XML qui résout les entités externes peut lire des fichiers ou contacter le réseau interne.
✅ Désactiver les entités externes du parseur.
démo à venir
SSRF
Forcer le serveur à requêter une URL interne (métadonnées cloud, services privés).
✅ Liste blanche des destinations, pas d'URL fournie par l'utilisateur.
démo à venir
Inclusion de fichier
Inclure dynamiquement un fichier d'après une entrée (LFI/RFI) pour exécuter du code arbitraire.
✅ Pas d'include dynamique basé sur l'entrée ; liste blanche.
démo à venir
Bac à sable éducatif Cyberini · démos confinées/simulées, 100 % navigateur, aucune donnée collectée.
Tester des failles sans autorisation est illégal.
C'est quoi une faille web ?
Une faille web est un défaut dans une application qui permet à un attaquant de faire ce qui
n'était pas prévu : exécuter du code (XSS), contourner une authentification (injection SQL),
payer moins cher (altération de paramètres), lire des fichiers, usurper une session… Les
comprendre « de l'intérieur », sur un bac à sable, est la meilleure façon d'apprendre à
les corriger. La référence du domaine est le Top 10 de l'OWASP.
Le fil rouge des correctifs
Presque toutes ces failles partagent une cause : faire confiance à une entrée
(de l'utilisateur, du navigateur, d'un fichier). Les parades se ressemblent donc : valider et
échapper les entrées/sorties, utiliser des requêtes préparées, ne jamais déléguer la sécurité au
client, et appliquer le principe de moindre privilège.
Questions fréquentes
Ces démos attaquent-elles un vrai site ?
Non. Tout est simulé en mémoire, et la démo XSS s'exécute dans une iframe isolée. Rien ne sort de votre navigateur.
Est-ce légal d'apprendre ça ?
Oui, sur un environnement d'entraînement comme celui-ci. Tester une faille sur un site sans autorisation est en revanche illégal.
Où m'entraîner pour de vrai ?
Sur des plateformes prévues pour (Root-Me, DVWA, PortSwigger Web Security Academy) et dans nos formations.
Envie de passer de « comprendre » à « savoir corriger et tester » ? Apprenez la sécurité web et le pentest pas à pas. Découvrir les formations Cyberini
