1. Introduction

Au début du Web, un formulaire HTML ne pouvait transmettre qu'une poignée de champs vers un script CGI. Trente ans plus tard, chaque session de navigateur ouvre des dizaines d'appels API, dialogue avec des microservices et consomme du code de bibliothèques chargées à la volée.

Au fil des années, la surface d'attaque s'est complexifiée, amenant de nouveaux vecteurs d’attaque. La communauté de cybersécurité a cherché des repères pour classer et catégoriser les nouvelles attaques.

C'est dans ce contexte que l'OWASP publie, depuis 2003, son Top 10, un classement des vulnérabilités Web les plus fréquentes.

L'objectif de cet article est de retracer vingt ans d'évolution des menaces Web au travers de l'OWASP, afin de comprendre quels facteurs ont été déterminants. Nous chercherons ensuite à en extraire les éléments clés pouvant impacter la sécurité Web de demain.

2. Présentation de l'OWASP « Top 10 »

L’Open Worldwide Application Security Project (OWASP) est une fondation à but non lucratif et une communauté mondiale créée en 2001 et dédiée à l’amélioration de la sécurité des logiciels.

Elle publie des ressources ouvertes et neutres : le WSTG (guide de tests), l’ASVS (référentiel de vérification), divers outils, ainsi que la famille des Top 10 (Web, API, Mobile, IA/LLM), afin d’aider chacun à sécuriser ses applications.

Le Top 10 Web sert de référentiel de sensibilisation qui hiérarchise les risques applicatifs Web les plus critiques, basé sur des données d’incidents, de tests de sécurité et de retours d’experts.

Il est publié toutes les quelques années : 2003, 2004, 2007, 2010, 2013, 2017 et 2021 (dernière version stable au moment de l’écriture). Une mise à jour est généralement attendue sur un cycle de 3-4 ans.

Par exemple, la dernière version en date du Top 10 couvre les risques suivants :

Mais avant d’en arriver là, dix-huit années se sont écoulées, marquées par des évolutions majeures du Top 10, comme l’illustre l’image suivante.

3. Chronologie

2003 - 2004

L'ère des entrées non validées et des XSS

Les deux premières éditions du Top 10, parues respectivement en 2003 et 2004, reflètent un Web encore largement construit en code “maison”, avec des scripts CGI/PHP et des assemblages ad hoc. La validation des entrées et la gestion de session restent peu maîtrisées. Logiquement, la catégorie Unvalidated Input domine le classement, devant les faiblesses d’authentification/contrôle d’accès et les XSS.

Le volume de vulnérabilités est élevé et l’exploitation souvent triviale. Le profil d’attaquant typique est opportuniste/novice, outillé de scanners et d’exploits publics ; leurs objectifs : visibilité (defacement), déni de service léger, prise de contrôle basique (hébergement de pages ou spam).

Particularité de 2003 : la présence de buffer overflows dans un classement pourtant orienté “Web”, signe que des parseurs ou modules C/C++ exposés au cœur des applications restaient des points faibles notables.

2005 - 2007

Web 2.0, AJAX et vulnérabilités XSS/CSRF/IDOR

Avec l’essor du Web 2.0 et d’AJAX (popularisé en 2005), les applications deviennent interactives sans rechargement. L’expérience utilisateur progresse, tout comme la surface d’attaque côté navigateur.

En 2007, le Top 10 OWASP place XSS en première position, suivi de l’Injection, de Malicious File Execution, d’IDOR et de CSRF. Ces deux derniers sont jugés particulièrement critiques : l’IDOR met en évidence les risques liés à l’utilisation d’identifiants prédictibles, tandis que le CSRF illustre les failles dues à une mauvaise gestion de l’état de session.

La prédominance de Malicious File Execution vient surtout des Remote File Inclusions PHP ; l’option allow_url_include=Off introduite par défaut dans PHP 5.2 et la montée en maturité des frameworks feront ensuite reculer cette famille.

Le profil d’attaquant évolue également : on ne vise plus seulement le defacement, mais aussi la récupération de données personnelles et l’abus d’actions authentifiées.

2010 - 2013

Configuration, composants vulnérables et montée en complexité

Entre 2010 et 2013, le Top 10 évolue pour refléter un Web plus industrialisé : les applications reposent désormais sur des frameworks et des bibliothèques tierces, ce qui change la nature des failles.

L’édition 2010 introduit Security Misconfiguration et Failure to Restrict URL Access, soulignant que la sécurité ne dépend pas seulement du code mais aussi des paramètres serveurs et frameworks. L’apparition de protections par défaut (comme la protection CSRF activée dans Django 1.2 en 2010) illustre ce glissement vers des pratiques de développement plus disciplinées.

En 2013, deux nouvelles entrées marquent une étape importante : l’apparition de Using Components with Known Vulnerabilities, reflet direct de la montée en puissance des écosystèmes de dépendances (npm, Maven, Bower…). Le risque lié aux chaînes d’approvisionnement logicielles devient tangible, jusqu’à être incarné quelques années plus tard par la fuite Equifax (2017) exploitant Apache Struts (CVE-2017-5638).

2017 - 2021

APIs, intégrité logicielle et risques cloud

L’édition 2017 reflète l’essor des API et des architectures distribuées. Deux nouvelles catégories apparaissent : XML External Entities (XXE), liée à des parseurs XML trop permissifs, et Insecure Deserialization, exploitable dans des frameworks Java ou PHP. On note aussi l’introduction de Insufficient Logging & Monitoring, reconnaissant que les attaques passent souvent inaperçues faute de détection. Pendant ce temps, Broken Access Control grimpe dans le classement, préfigurant l’ère des API ...

En 2021, la hiérarchie change profondément : Broken Access Control passe en première position, tandis que XSS est absorbé dans la catégorie plus large Injection. Deux nouvelles entrées élargissent la perspective : Insecure Design, qui pousse à intégrer la sécurité dès la conception, et Software & Data Integrity Failures, rappelant les risques liés aux pipelines CI/CD et aux mises à jour critiques. L’année est marquée par des incidents comme SolarWinds (2020) et Log4Shell (2021)...

4. Facteurs notables

Des sites simples aux écosystèmes distribués.

En vingt ans, nous sommes passés du “site Web” isolé à des architectures faites d’API, de microservices et d’intégrations partenaires. Chaque nouvel élément ouvre une porte supplémentaire, et donc plus d’occasions de rater un contrôle.

Durcissement par défaut… et déplacement des attaques.

Navigateurs et frameworks ont corrigé une partie des erreurs classiques (échappement, CSRF, en-têtes de sécurité). Les attaquants se sont donc déplacés vers ce qui échappe aux protections automatiques : l’autorisation (qui peut faire quoi, sur quel objet) et la logique métier, mais parfois aussi des failles plus complexes comme les attaques par désérialisation.

Explosion des dépendances et de la supply chain.

Nos applications reposent sur des dizaines de bibliothèques et de scripts tiers. Une faille dans un composant ou un pipeline CI/CD se propage à toute l’application. La sécurité n’est plus seulement « écrire du bon code », c’est gérer un inventaire vivant et la confiance dans tout ce qu’on intègre.

DevOps et cloud : vitesse + configurations.

La livraison continue et le cloud accélèrent l’innovation, mais le risque se déplace vers les mauvais réglages (permissions trop larges, secrets exposés, stockages ouverts) et l’hygiène opérationnelle.

Voir pour agir.

Les attaques modernes sont discrètes. Sans journaux fiables, métriques et alertes utiles, on découvre les incidents trop tard. L’observabilité devient une capacité métier : mesurer, détecter, réagir.

À retenir : le risque s’est déplacé du bug “brut” vers l’autorisation, la configuration et la chaîne d’approvisionnement, dans des systèmes plus distribués et rapides.

5. Perspectives futures

OWASP Top 10:2025 : affiner le prisme “Web”.

La prochaine édition du Top 10, attendue pour fin 2025, devrait prolonger les tendances observées ces dernières années : Broken Access Control a toutes les raisons de rester en tête, tandis que la famille des injections demeure un fil rouge. La supply chain logicielle et la sécurité API/cloud devraient, elles, gagner en granularité.

IA générative : productivité spectaculaire, dettes de sécurité bien réelles.

Les assistants de code accélèrent la livraison, mais ils peuvent introduire des patterns obsolètes ou ignorer des contrôles d’autorisation. Le remède n’est pas de freiner l’adoption, mais de l’industrialiser : scans systématiques (SAST/DAST/Secrets/IaC), policy as code, tests de sécurité et traçabilité des suggestions d’IA.

Contenu qui attaque le code : l’“indirect prompt injection” version Web.

À l’avenir, les applications traiteront du contenu externe, parfois hostile, capable de manipuler la logique applicative. Les mesures à anticiper incluent une séparation stricte entre données et instructions et une journalisation infalsifiable.

HTTP/3 : attaques de “désynchronisation” nouvelle génération.

La pile réseau évolue avec le multiplexage, la diversité des proxys et l’essor des calculs en périphérie. Les vulnérabilités historiques se transforment sous l’effet de nouveaux parseurs et des architectures CDN. Les tests devront reproduire la chaîne complète pour détecter les incohérences.

Front industriel sous contrôle continu.

L’avenir du Web côté client ne réside pas dans une réduction des dépendances, mais dans un renforcement du contrôle : adoption systématique du SRI, activation par défaut de Trusted Types, inventaires automatisés des scripts, et alertes en temps réel.

En résumé : les évolutions majeures du Web ne tiennent pas à l’apparition de nouveaux sigles, mais à la transposition des problématiques d’autorisation, d’intégrité et de parsing au plus près du navigateur, des API et de l’edge.

6. Conclusion

En un peu plus de vingt ans, le « Top 10 » est passé du filtrage de formulaires à l’orchestration de chaînes logicielles globales. Si les injections n’ont jamais vraiment disparu, l’essentiel du danger s’est déplacé : de la ligne de code vers la conception, puis vers l’écosystème.

La vigilance, aujourd’hui, ne consiste plus seulement à patcher un fichier PHP, mais à savoir quelles briques composent son logiciel, comment elles communiquent et qui les opère. Armés de cette grille de lecture historique, les concepteurs et auditeurs peuvent mieux hiérarchiser leurs efforts et réduire l’écart entre innovation et sécurité.