Panorama OWASP Top 10

Avant de commencer

Pourquoi cette séance

Tu sais construire une application. Il est temps d'apprendre à la défendre — et pour ça, à penser comme un attaquant. L'OWASP Top 10 est la référence mondiale : une liste, mise à jour régulièrement par la communauté sécurité, des 10 catégories de vulnérabilités les plus graves et les plus fréquentes sur le web. C'est le socle de l'épreuve E7 (écrit 4h, Bloc 3) et de tout cet arc cyber. Aujourd'hui, vue d'ensemble : on nomme chaque famille, on voit à quoi elle ressemble sur AppliFrais, et on pose le vocabulaire. Les séances suivantes attaqueront chacune en détail.

Penser en attaquant ET en défenseur

Pour chaque faille, tu vas apprendre les deux côtés. C'est ça, la sécurité applicative :

0. C'est quoi, l'OWASP ?

OWASP = Open Worldwide Application Security Project. Une fondation à but non lucratif qui produit des ressources libres sur la sécurité applicative. Son document le plus célèbre : le Top 10.

La différence faille / exploit / vulnérabilité

Que cherche un attaquant ? Le triangle D-I-C

Une attaque vise toujours à casser au moins une des trois garanties qu'un service doit à ses utilisateurs. On les retrouve derrière chaque famille OWASP, et c'est un repère central de l'E7.

Le cycle de vie d'une attaque — où frappent les familles OWASP ?

Une attaque réelle se déroule en phases successives. Chaque famille OWASP frappe à une phase précise : comprendre ce schéma te donne la grille de lecture de tous les rapports de pentest et des sujets E7 — quand on te demande « comment se protéger ? », la réponse dépend de quand l'attaque frappe.

Cycle de vie d'une attaque. Les familles les plus critiques (A01, A02, A03) frappent à l'Exploitation. A04 (mauvaise conception) crée les failles qui permettent l'Exploitation. A09 (absence de logs) est la raison pour laquelle la zone Défense reste aveugle. C'est la grille de lecture de tout rapport de pentest.

Comment mesure-t-on la gravité d'une faille ? Le score CVSS

Quand on lit des CVE (Common Vulnerabilities and Exposures) ou des rapports de pentest, une faille est toujours accompagnée d'un score CVSS (Common Vulnerability Scoring System, version 3.1). C'est une note de 0 à 10 qui résume la dangerosité.

Pour les grandes familles OWASP, voici les scores CVSS typiques observés sur des CVE réelles :

1. Les 10 familles, en un coup d'œil

Voici la carte complète. Garde-la sous les yeux : c'est ta table des matières pour tout l'arc cyber.

* Sources : rapport OWASP Top 10 2021, NVD (National Vulnerability Database). Fréquence = proportion d'applis présentant la faille lors d'audits réels.

Famille → contre-mesure générique

Chaque famille a une parade « réflexe ». Tu l'approfondiras dans sa séance dédiée ; garde ce tableau comme aide-mémoire pour l'E7 (on te demandera souvent : « comment corriger ? »). Les détails techniques concrets sont ce que l'E7 attend — pas seulement « sécuriser le code ».

La feuille de route de l'arc cyber

Ce panorama est la boussole. Voici comment l'arc s'enchaîne ensuite — garde-la pour savoir où tu vas.

2. AppliFrais, ton terrain d'entraînement

Pour apprendre, on a besoin d'une application qu'on a le droit de casser. Ce sera AppliFrais — la tienne, montée en local, dans une version qu'on rendra volontairement vulnérable pour l'exercice.

La surface d'attaque d'AppliFrais

Surface d'attaque d'AppliFrais : tout ce qui vient du client (rouge) est NON fiable. Chaque entrée doit passer la « porte » de validation/autorisation (vert) avant d'atteindre le serveur, la base et le stockage.

3. Les failles phares, en avant-goût

Trois familles que tu rencontreras le plus souvent — juste de quoi sentir le mécanisme (le détail viendra dans leurs séances dédiées).

A03 — Injection (le plus parlant — deux variantes)

Le principe : une donnée du client est interprétée comme du code au lieu d'être traitée comme une simple valeur. Il en existe plusieurs formes — en connaître deux te donne la logique générale.

Variante 1 — Injection NoSQL (MongoDB, ton stack AppliFrais)

// VULNERABLE : la saisie de l'utilisateur entre directement dans la requete
db.collection('users').find({ email: req.body.email });
// si req.body.email vaut { "$ne": null }, la requete renvoie TOUS les users

POST /api/login
Content-Type: application/json

{ "email": { "$ne": null }, "password": { "$ne": null } }

HTTP/1.1 200 OK
{ "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...", "role": "comptable" }

// SUR : on impose que email soit bien une chaine avant de l'utiliser
if (typeof req.body.email !== 'string') return res.sendStatus(400);
if (typeof req.body.password !== 'string') return res.sendStatus(400);
db.collection('users').find({ email: req.body.email });

Variante 2 — Injection SQL (contexte GSB Ordonnances 1A, MySQL)

// VULNERABLE (C# / MySQL) : concatenation directe dans la requete
string query = "SELECT * FROM medecin WHERE login='" + login + "' AND mdp='" + mdp + "'";
MySqlCommand cmd = new MySqlCommand(query, conn);

// Sortie cote serveur : la requete envoyee a MySQL est :
SELECT * FROM medecin WHERE login='admin' --' AND mdp='nimportequoi'
// Le commentaire -- neutralise tout ce qui suit -> login reussi

// SUR (C# / MySQL) : requete parametree (AddWithValue)
string query = "SELECT * FROM medecin WHERE login=@login AND mdp=@mdp";
MySqlCommand cmd = new MySqlCommand(query, conn);
cmd.Parameters.AddWithValue("@login", login);
cmd.Parameters.AddWithValue("@mdp", mdp);

A01 — Broken Access Control

// VULNERABLE : la route ne verifie pas QUI demande
router.patch('/api/fiches/:id/valider', valider);
// un visiteur peut valider sa propre fiche -> il s'auto-rembourse

// SUR : un middleware verifie le role AVANT d'executer l'action
router.patch('/api/fiches/:id/valider', requireRole('comptable'), valider);

A02 — Cryptographic Failures

// VULNERABLE : mot de passe stocke en clair
await User.create({ email, password: req.body.password });
// si la base fuite, tous les mots de passe sont lisibles

// SUR : on hache le mot de passe avant de le stocker
const hash = await bcrypt.hash(req.body.password, 12);
await User.create({ email, password: hash });

Pourquoi bcrypt et pas SHA-256 ?

C'est la question que tout développeur se pose au moins une fois. Voici la vraie réponse :

Et les tokens JWT ? Le vrai risque

JWT (JSON Web Token) n'est pas un système d'authentification — c'est un format de token signé. Les erreurs classiques :

A05 — Security Misconfiguration : les en-têtes que tout le monde oublie

La plupart des frameworks ne configurent pas de sécurité par défaut. Une app Express fraîche répond avec 0 en-tête de sécurité. helmet.js en ajoute 8 d'un coup.

// Sans helmet (ce qu'Express retourne par defaut)
HTTP/1.1 200 OK
X-Powered-By: Express    // divulgue le framework — retirer en premier
Content-Type: application/json

// Avec helmet (une ligne dans app.js)
const helmet = require('helmet');
app.use(helmet());  // active les 8 en-tetes suivants automatiquement

A06 — Composants vulnérables : npm audit pas à pas

86 % des applications web utilisent des dépendances open source. Une seule d'entre elles peut contenir une faille connue (comme Log4Shell, CVSS 10,0 — dans une bibliothèque Java utilisée par des millions de serveurs). npm audit est ton scanner de dépendances : il compare ton package-lock.json avec la base NVD (National Vulnerability Database) et te liste les CVE connues. C'est la commande à lancer avant chaque déploiement.

npm audit --audit-level=high

found 2 vulnerabilities (1 high, 1 critical)

  critical  GHSA-c2qf-rxjj-qqgw  — express 4.17.1
  Package    express
  Severity   critical
  Title      Open Redirect via malformed URL
  URL        https://github.com/advisories/GHSA-c2qf-rxjj-qqgw
  Fix Available  Yes  --  run: npm audit fix

  high  GHSA-rv95-896h-c2vc  — axios >=0.8.1 <1.6.0
  Package    axios
  Severity   high
  Title      Regular Expression Denial of Service (ReDoS)
  URL        https://github.com/advisories/GHSA-rv95-896h-c2vc
  Fix Available  Yes  --  run: npm audit fix

Run `npm audit fix` to fix 2 of 2 issues.
npm audit fix

npm audit fix          # corrige en montant de version mineure (safe, respecte semver)
npm audit fix --force  # force les mises a jour majeures (peut casser l'API — relancer les tests)

A09 — Logging Failures : que journaliser — et que ne jamais journaliser

Sans logs, une attaque passée en phase Exploitation reste invisible en moyenne 207 jours (IBM Cost of a Data Breach, 2023). Les logs sont la mémoire de l'application — sans eux, tu es aveugle. Mais mal configurés, les logs deviennent eux-mêmes une faille (mots de passe en clair dans les fichiers de log).

// CE QU'ON DOIT LOGGER — exemples avec winston ou console structuree
logger.info('LOGIN_SUCCESS', { userId, role, ip: req.ip, ts: Date.now() });
logger.warn('LOGIN_FAIL',    { email: req.body.email, ip: req.ip, ts: Date.now() });
logger.error('ACCESS_DENIED',{ userId, route: req.path, method: req.method, ts: Date.now() });
logger.info('FICHE_VALIDEE', { ficheId, comptableId, montant, ts: Date.now() });

// CE QU'ON NE DOIT JAMAIS LOGGER
logger.info('USER_DATA',  { password: req.body.password });  // JAMAIS le mot de passe
logger.debug('JWT_TOKEN', { token });                         // JAMAIS le token complet
logger.info('SEARCH',     { query: req.body });               // si body contient un mdp/token

Exercice de lecture de code — identifie la famille OWASP

Trois extraits de code tirés d'une version vulnérable d'AppliFrais. Pour chacun : identifie la ou les familles OWASP concernées, explique le risque, propose la correction. Essaie d'abord par toi-même, puis ouvre le corrigé juste en-dessous. C'est exactement ce que l'E7 te demande.

Extrait 1 — Route de suppression

// routes/fiches.js
router.delete('/api/fiches/:id', async (req, res) => {
  const fiche = await Fiche.findByIdAndDelete(req.params.id);
  res.json({ deleted: fiche._id });
});

Extrait 2 — Recherche de visiteurs

// routes/visiteurs.js
router.get('/api/visiteurs', async (req, res) => {
  const visiteurs = await Visiteur.find({ nom: req.query.nom });
  res.json(visiteurs);
});

Extrait 3 — Middleware d'authentification

// middleware/auth.js
function authenticate(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.sendStatus(401);
  const payload = jwt.verify(token, process.env.JWT_SECRET);
  req.user = payload;
  next();
}

function authenticate(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.sendStatus(401);
  try {
    const payload = jwt.verify(token, process.env.JWT_SECRET, { algorithms: ['HS256'] });
    req.user = payload;
    next();
  } catch (err) {
    return res.sendStatus(401); // ne PAS retourner err.message : divulgue l'archi
  }
}

4. Mini-projet : cartographier AppliFrais

La mission

Tu vas produire la carte de menace d'AppliFrais : un document de référence que tu enrichiras à chaque séance de l'arc cyber.

1. reprends les 10 familles OWASP ;
2. pour chacune, écris où elle pourrait frapper dans AppliFrais (quel point d'entrée, quelle fonctionnalité) ;
3. note pour chacune si tu penses ton AppliFrais exposé ou protégé (à ce stade, une intuition suffit) ;
4. classe les 3 que tu juges les plus risquées pour ton appli.

OWASP et le RGPD : la double peine

Certaines failles OWASP, si elles provoquent une fuite de données personnelles, déclenchent en plus une obligation RGPD. En France, la CNIL peut sanctionner indépendamment de toute sanction pénale. Voici les croisements à connaître pour l'E7 :

Pour finir

Ce que tu emportes

Vérifie tes acquis — quiz corrigé

Glossaire