Le jour où votre code parfait vous trahit
Vous livrez un formulaire de connexion. Il marche : email, mot de passe, et hop, le tableau de bord s'affiche. Les tests passent au vert. Le client sourit. Vous passez à la tâche suivante, tranquille.
Trois semaines plus tard, un parfait inconnu se connecte en administrateur, sans connaître le moindre mot de passe. Son secret ? Il a tapé, dans le champ email, quelque chose comme ' OR '1'='1' --. Votre formulaire n'a pas bugué une seconde : il a fait exactement ce que vous lui aviez demandé. Le souci, c'est que vous ne saviez pas tout ce que vous étiez en train de lui demander.
Voilà le cœur de la sécurité. Ce n'est pas une couche de peinture qu'on passe à la fin. C'est une façon de penser, le "mindset" comme on dit dans le métier, qui change la question que vous posez à votre propre code.
Construire vs casser : deux cerveaux
Un développeur se demande : « comment je fais marcher ce truc ? ». Il imagine le gentil utilisateur, celui qui remplit les champs comme prévu, clique où il faut et suit sagement le chemin balisé. Ce chemin idéal porte un nom : le happy path, le chemin heureux.
L'attaquant, lui, se demande l'inverse : « comment je fais péter ce truc ? ». Il ne suit aucun chemin. Il colle 10 000 caractères dans un champ « prénom ». Il glisse un prix négatif dans son panier pour que la boutique lui doive de l'argent. Il change le id=42 de l'URL en id=43 pour lire la facture du voisin. Et souvent, il n'ouvre même pas votre jolie page : il parle directement au serveur depuis un terminal.
Toute la bascule de ce cours tient dans une phrase, à se tatouer quelque part : toute donnée qui vient de l'extérieur est hostile jusqu'à preuve du contraire. Le navigateur de l'utilisateur ne vous appartient pas. Tout ce qui en sort a pu être trafiqué, modifié ou rejoué par quelqu'un qui ne vous veut pas que du bien.
Voici un champ de recherche tout bête sur un site. Avant de dérouler la réponse : citez trois façons dont un attaquant pourrait en abuser, alors que vous, vous y voyez juste « une barre où on tape un mot ».
Voir des pistes
Trois exemples parmi d'autres :
- Y taper du code (SQL, HTML, JavaScript) pour qu'il soit exécuté côté serveur ou chez les autres visiteurs (injection, XSS : leçons 3 et 4).
- Y coller un texte démesuré ou des caractères bizarres (unicode, emoji, octets nuls) pour faire planter ou déborder le traitement.
- Envoyer la recherche des milliers de fois par seconde depuis un script, pour saturer le serveur ou deviner des données par essais successifs.
Vous n'avez pas à connaître les attaques encore : ce qui compte, c'est d'avoir arrêté de voir « un champ de texte » et commencé à voir « une porte ouverte sur mon serveur ».
Les règles du jeu : éthique et loi
Apprendre à attaquer pour mieux défendre, c'est non seulement légitime, c'est la meilleure façon d'apprendre. Mais il y a une ligne rouge, et elle est juridique, pas seulement morale.
Sur vos propres systèmes ou sur des plateformes d'entraînement faites pour ça : éclatez-vous, c'est légal. Sur le site de quelqu'un d'autre « pour rendre service » ou « juste pour voir », même sans rien casser : illégal, point. En France, le simple fait d'accéder ou de se maintenir frauduleusement dans un système est puni par l'article 323-1 du code pénal (jusqu'à 3 ans de prison et 100 000 € d'amende), et la bonne intention ne vous sauvera pas. La plupart des pays ont leur équivalent.
Ne lancez jamais une attaque, même « inoffensive », contre un système dont vous n'êtes pas propriétaire et pour lequel vous n'avez pas une autorisation écrite définissant le périmètre. C'est la règle numéro un de tout métier de la sécurité.
Pour pratiquer l'offensif « pour de vrai » et légalement, entraînez-vous sur des terrains conçus exprès : la Web Security Academy de PortSwigger (gratuite), OWASP Juice Shop (à installer en local), picoCTF ou, en français, Root-Me.
Maintenant que les règles du jeu sont claires, reste à savoir quels dangers concrets guetter : c'est là qu'entre en scène l'OWASP.
OWASP Top 10 : la carte du territoire
L'OWASP (Open Worldwide Application Security Project) est une fondation à but non lucratif qui publie, depuis 2003, le hit-parade des dix risques de sécurité web les plus critiques. C'est la référence commune de toute la profession : quand un audit ou un client parle de « couvrir l'OWASP Top 10 », c'est de cette liste qu'on parle. Voyez ça comme le bestiaire des dix monstres que vous croiserez le plus souvent.
Voici l'édition 2025, du plus fréquent au plus pointu :
- A01 Contrôle d'accès défaillant : accéder à des données ou des actions qui ne devraient pas vous être permises (leçon 6).
- A02 Mauvaise configuration de sécurité : réglages par défaut, headers manquants, services exposés (leçons 10 et 11).
- A03 Failles de la chaîne d'approvisionnement : une dépendance vulnérable devient votre faille (leçon 13).
- A04 Défaillances cryptographiques : données sensibles mal ou pas chiffrées, mauvais hachage (leçon 12).
- A05 Injection : du code hostile glissé dans une donnée, dont l'injection SQL et le XSS (leçons 3, 4, 5).
- A06 Conception non sécurisée : la faille est dans le plan, pas dans le code (leçon 2).
- A07 Défaillances d'authentification : se faire passer pour quelqu'un d'autre (leçons 7, 8).
- A08 Défauts d'intégrité des données et du logiciel : faire confiance à du code ou des données non vérifiés (leçon 13).
- A09 Défaillances de journalisation et d'alerte : ne pas voir l'attaque qui arrive (leçon 14).
- A10 Mauvaise gestion des conditions exceptionnelles : les erreurs et cas limites mal traités qui ouvrent des brèches (leçon 14).
À savoir : ce classement est révisé tous les quelques années à partir de données réelles de vulnérabilités. L'ordre et les catégories bougent d'une édition à l'autre. Ce qui compte n'est pas de réciter la liste par cœur, mais de reconnaître chaque famille de risque dans votre propre code, ce que les leçons suivantes vont vous apprendre une par une.
Règle d'or du cours : chaque leçon suivra le même rythme. On voit l'attaque (pourquoi ça casse), puis le correctif (comment ça tient), puis pourquoi ce correctif est le bon. On ne s'arrête jamais à « voilà comment exploiter » : on referme toujours sur la défense.
The day your perfect code betrays you
You ship a login form. It works: email, password, and boom, the dashboard shows up. Tests pass, all green. The client smiles. You move on to the next task, relaxed.
Three weeks later, a total stranger logs in as an administrator, without knowing a single password. Their secret? They typed, in the email field, something like ' OR '1'='1' --. Your form didn't glitch for a second: it did exactly what you asked it to. The catch is that you didn't know everything you were asking it to do.
That's the heart of security. It isn't a coat of paint you add at the end. It's a way of thinking, what the industry calls the "mindset", that changes the question you ask your own code.
Building vs breaking: two brains
A developer asks: "how do I make this thing work?". They picture the friendly user, the one who fills the fields as intended, clicks where they should and follows the marked path. That ideal path has a name: the happy path.
The attacker asks the opposite: "how do I make this thing blow up?". They follow no path. They paste 10,000 characters into a "first name" field. They slip a negative price into their cart so the shop owes them money. They change id=42 in the URL to id=43 to read the neighbor's invoice. And often they don't even open your pretty page: they talk straight to the server from a terminal.
The whole switch of this course fits in one sentence, worth tattooing somewhere: any data coming from the outside is hostile until proven otherwise. The user's browser is not yours. Anything coming out of it may have been tampered with, modified, or replayed by someone who doesn't wish you well.
Here is a plain search box on a website. Before you expand the answer: name three ways an attacker could abuse it, while you only see "a bar where you type a word".
Show some leads
Three examples among others:
- Type code into it (SQL, HTML, JavaScript) so it runs on the server or in other visitors' browsers (injection, XSS: lessons 3 and 4).
- Paste an oversized text or weird characters (unicode, emoji, null bytes) to crash or overflow the processing.
- Send the search thousands of times per second from a script, to overload the server or guess data by trial and error.
You don't need to know the attacks yet: what matters is that you stopped seeing "a text field" and started seeing "an open door into my server".
The rules of the game: ethics and the law
Learning to attack in order to better defend isn't just legitimate, it's the best way to learn. But there's a red line, and it's legal, not just moral.
On your own systems or on training platforms built for it: go wild, it's legal. On someone else's site "to help" or "just to see", even without breaking anything: illegal, full stop. In France, merely accessing or staying fraudulently inside a system is punished by article 323-1 of the penal code (up to 3 years in prison and a €100,000 fine), and good intentions won't save you. Most countries have their equivalent (the Computer Fraud and Abuse Act in the US, the Computer Misuse Act in the UK).
Never launch an attack, even a "harmless" one, against a system you don't own and for which you don't have a written authorization defining the scope. That's rule number one of every security job.
To practice offense "for real" and legally, train on grounds built for it: PortSwigger's Web Security Academy (free), OWASP Juice Shop (run it locally), picoCTF or Root-Me.
Now that the rules of the game are clear, the next question is: which concrete threats should you watch for? That's where OWASP comes in.
OWASP Top 10: the map of the territory
The OWASP (Open Worldwide Application Security Project) is a non-profit foundation that has published, since 2003, the chart of the ten most critical web security risks. It's the common reference for the whole profession: when an audit or a client talks about "covering the OWASP Top 10", this is the list they mean. Think of it as the bestiary of the ten monsters you'll meet most often.
Here is the 2025 edition, from most frequent to most niche:
- A01 Broken Access Control: reaching data or actions that shouldn't be allowed to you (lesson 6).
- A02 Security Misconfiguration: default settings, missing headers, exposed services (lessons 10 and 11).
- A03 Software Supply Chain Failures: a vulnerable dependency becomes your flaw (lesson 13).
- A04 Cryptographic Failures: sensitive data poorly encrypted or not at all, bad hashing (lesson 12).
- A05 Injection: hostile code slipped into data, including SQL injection and XSS (lessons 3, 4, 5).
- A06 Insecure Design: the flaw is in the blueprint, not the code (lesson 2).
- A07 Authentication Failures: impersonating someone else (lessons 7, 8).
- A08 Software & Data Integrity Failures: trusting unverified code or data (lesson 13).
- A09 Logging & Alerting Failures: not seeing the attack coming (lesson 14).
- A10 Mishandling of Exceptional Conditions: mishandled errors and edge cases that open breaches (lesson 14).
Good to know: this ranking is revised every few years from real vulnerability data. The order and categories shift from one edition to the next. What matters isn't reciting the list by heart, but recognizing each family of risk in your own code, which the next lessons will teach you one by one.
Golden rule of the course: every lesson follows the same rhythm. We see the attack (why it breaks), then the fix (how it holds), then why that fix is the right one. We never stop at "here's how to exploit it": we always close on the defense.
🎯 Pratique
S'entraîner (clique pour ouvrir) :
✨ Prompt IA
Copiez ce prompt dans Claude ou ChatGPT :
Joue le rôle d'un attaquant face à ce formulaire de connexion (email + mot de passe). Liste tout ce que tu essaierais pour le contourner, en expliquant l'idée derrière chaque tentative. Puis, pour chaque attaque, dis-moi en une phrase comment un développeur s'en protège.
💬 Ré-explique sans regarder
Avec tes mots : en quoi la question que se pose un attaquant devant un formulaire est différente de celle que se pose le développeur qui l'a écrit ? Et pourquoi « valider seulement dans le navigateur » ne protège de rien ?
🧠 Rappel libre
Sans remonter dans la leçon : qu'est-ce que l'OWASP Top 10, et quelle est la règle absolue avant de tester une attaque sur un système qui n'est pas le vôtre ?
You've got the right reflex: everything is hostile until proven otherwise. But faced with a real application, where do you start? Lesson 2 gives you a method: map the attack surface and stack defenses so no single flaw is fatal.
Lesson 2: Threat modeling →