Auto-évaluationGlossaire

Chapitre 8 — Architecture Web & OWASP Top 10

⏱ ~30 min autonome · ~45 min encadré

La sécurité des applications web mérite un chapitre approfondi : c'est le domaine où la surface d'attaque a le plus grandi ces vingt dernières années, et celui que ce cours choisit délibérément de couvrir avec le plus de profondeur.

Fonctionnement client-serveur, HTTP/HTTPS

Une application web repose sur un échange de requêtes et de réponses entre un client (navigateur) et un serveur, via le protocole HTTP — ou sa version chiffrée, HTTPS, qui protège la confidentialité et l'intégrité des échanges via TLS (voir Chapitre 11). Chaque requête est, par nature, indépendante des précédentes — HTTP est un protocole sans état (stateless).

Sessions et cookies

Puisque HTTP ne conserve aucun état entre deux requêtes, les applications utilisent des cookies pour simuler une continuité — un identifiant de session stocké côté client et renvoyé à chaque requête, permettant au serveur de savoir « qui » fait la demande. Un cookie de session mal protégé (transmis sans chiffrement, accessible via JavaScript, sans expiration) devient une cible de choix : le voler équivaut souvent à usurper entièrement l'identité de la victime, sans jamais avoir besoin de son mot de passe.

Surface d'attaque d'une application web moderne

Une application web typique expose bien plus qu'un simple formulaire : des API, des dépendances tierces (bibliothèques, frameworks), des services d'authentification externes, et souvent une infrastructure cloud sous-jacente (voir Chapitre 10) — chaque composant ajoute sa propre surface d'attaque potentielle.

L'OWASP Top 10 est un document de référence gratuit et régulièrement mis à jour, représentant un consensus de l'industrie sur les risques les plus critiques pour les applications web. Il structure ce chapitre et le suivant. Aperçu des dix catégories — développées en profondeur dans l'annexe dédiée :

  1. Contrôle d'accès défaillant — un utilisateur agit en dehors des permissions prévues.
  2. Défaillances cryptographiques — mauvaise protection des données sensibles.
  3. Injection — une entrée non validée est interprétée comme du code (voir section 8.3).
  4. Conception non sécurisée — l'architecture elle-même est vulnérable, indépendamment de son implémentation.
  5. Mauvaise configuration de sécurité — comptes par défaut, erreurs trop verbeuses.
  6. Composants vulnérables et obsolètes — dépendances non corrigées.
  7. Défaillances d'identification et d'authentification — connexion mal protégée.
  8. Défaillances d'intégrité logicielle et des données — mises à jour non vérifiées.
  9. Défaillances de journalisation et de surveillance — intrusion invisible faute de détection.
  10. Falsification de requête côté serveur (SSRF) — le serveur est trompé pour atteindre des ressources internes normalement inaccessibles.
Mémorisez ! L'OWASP Top 10 n'est pas une liste figée — chaque édition fusionne, renomme ou ajoute des catégories selon l'évolution réelle des risques observés dans l'industrie. C'est un consensus à un moment donné, pas une norme immuable.
Scénario : Une application affiche un message d'erreur détaillé (« Erreur SQL : colonne 'password' introuvable dans la table 'utilisateurs_v2' ») lorsqu'une requête échoue. Sans qu'aucune donnée n'ait été volée, ce message expose la structure interne de la base de données — un exemple classique de mauvaise configuration de sécurité (catégorie 5), qui facilite grandement une injection ultérieure (catégorie 3).

Suite du chapitre → Injection SQL

1. Pourquoi les applications web utilisent-elles des cookies de session ?

HTTP ne conserve aucun état entre requêtes ; les cookies de session permettent de relier plusieurs requêtes à un même utilisateur.

2. Voler le cookie de session d'un utilisateur permet typiquement à un attaquant de :

Un cookie de session volé peut suffire à usurper une session active, sans jamais avoir besoin du mot de passe réel.

3. Quelle catégorie de l'OWASP Top 10 couvre le fait qu'une entrée non validée soit interprétée comme du code ?

L'injection désigne précisément ce mécanisme : une entrée traitée à tort comme du code exécutable.

4. Un message d'erreur détaillé révélant la structure d'une base de données illustre principalement quelle catégorie ?

Un message d'erreur trop verbeux qui expose des détails d'implémentation est un exemple classique de mauvaise configuration.

5. Qu'est-ce qui distingue une « conception non sécurisée » d'un simple défaut d'implémentation ?

Une conception non sécurisée est un défaut architectural, présent même avec une implémentation techniquement irréprochable.

6. Pourquoi l'OWASP Top 10 change-t-il de contenu d'une édition à l'autre ?

Le document évolue pour refléter les risques réellement observés à un moment donné dans l'industrie.

7. Que permet une attaque de type SSRF (falsification de requête côté serveur) ?

Le SSRF exploite le serveur lui-même comme intermédiaire pour atteindre des systèmes internes protégés.

8. Quelle catégorie OWASP couvre l'utilisation de bibliothèques ou frameworks non corrigés ?

Cette catégorie couvre spécifiquement les dépendances (bibliothèques, frameworks, OS) non mises à jour.

9. Pourquoi l'absence de journalisation suffisante est-elle considérée comme un risque de sécurité applicative ?

Sans journalisation ni surveillance active, une compromission peut passer inaperçue pendant une durée prolongée.

10. Une application web moderne intègre typiquement des API, des dépendances tierces et une infrastructure cloud. Cela illustre :

Chaque composant supplémentaire (API, dépendances, cloud) élargit la surface d'attaque totale de l'application.