refonte OWASP

# Bloc 3 — Vulnérabilités des SI

## Fiche 3 : Sécurité d'un service web — OWASP

Cette fiche récapitulative s'appuie sur plusieurs sources accessibles via les liens intégrés au texte. N'hésitez pas à les consulter pour approfondir.

⚠️ **Attention : il s'agit d'un résumé très condensé.**

Il est fortement recommandé de cliquer sur les liens associés à chaque vulnérabilité : ils renvoient vers le site officiel de l'OWASP, où vous trouverez une description complète, les mesures de mitigation et les CWE correspondantes.

## OWASP : présentation

L'**Open Web Application Security Project** ([OWASP](https://fr.wikipedia.org/wiki/Open_Web_Application_Security_Project)) est une communauté internationale dédiée à la sécurité des applications web.

Elle publie notamment le **Top 10 OWASP**, une liste des risques de sécurité les plus critiques pour sensibiliser les développeurs et les responsables techniques.

Le Top 10 a été révisé en 2010, 2013, 2017, 2021 et 2025. La version la plus récente est disponible ici : **[OWASP Top Ten 2025](https://owasp.org/Top10/2025/0x00_2025-Introduction/)**.

![img](ficheowasp-img/top10-changelogs-1024x282.png)

![img](ficheowasp-img/2025-mappings.png)

## Ce qui change : 2021 → 2025

### Nouvelles catégories / consolidation / refonte

* Dans la version 2025, la catégorie **Software Supply Chain Failures** (A03) apparaît — elle remplace et élargit l'ancienne **Vulnerable and Outdated Components** de 2021. Elle couvre désormais non seulement les composants obsolètes, mais l'ensemble de l'écosystème logiciel : dépendances, outils de build, distribution, chaîne d'approvisionnement logicielle. 

* Toujours en 2025, la catégorie **Mishandling of Exceptional Conditions** (A10) est ajoutée. Elle traite des erreurs de gestion des conditions exceptionnelles — gestion d'erreurs, états inattendus, « fail-open », logique défaillante, etc

* Par ailleurs, l'ancienne catégorie **Server‑Side Request Forgery** (SSRF), qui était A10 dans 2021, n'existe plus en tant que catégorie autonome : elle a été **fusionnée** dans **Broken Access Control** (A01) en 2025.

Ainsi, la modification du top-10 ne se limite pas à un simple remaniement de noms ou positions : certaines catégories changent de périmètre, de dimension, ou fusionnent.

## Pourquoi ces changements — ce que cela signifie concrètement

* L'arrivée de **Software Supply Chain Failures** montre que la sécurité ne se limite plus au code que l'on écrit : **toute la chaîne — dépendances, build, distribution, infrastructure — devient un vecteur critique**. Il faut désormais surveiller les bibliothèques tierces, les pipelines de CI/CD, les services externes, les conteneurs, etc. ([aikido.dev][1])

* L'ajout de **Mishandling of Exceptional Conditions** souligne que **la gestion des erreurs, des cas limites, des situations imprévues est un risque à part entière** : un échec mal géré, un « fail open », un état instable, un retour d'erreur trop verbeux peuvent exposer des failles. ([Reflectiz][5])

* La remontée de **Security Misconfiguration** en 2ᵉ place montre la persistance (et peut-être l'aggravation) des erreurs de configuration — dans des environnements de plus en plus complexes (cloud, conteneurs, microservices, etc.). ([soprasteria.be][6])

* Le glissement de catégories comme Injection ou Cryptographic Failures vers des rangs plus bas n'indique pas qu'elles sont devenues « sans risque » — mais simplement que, dans les données récentes et les votes communautaires, d'autres vecteurs (supply-chain, design, erreurs) apparaissent comme plus prégnants. ([owasp.org][2])

* Enfin, le renommage de certaines catégories (ex. « Logging & Monitoring » → « Logging & Alerting », « Identification and Authentication Failures » → « Authentication Failures ») montre un effort pour **clarifier le périmètre et le rôle exact de la catégorie**, ce qui facilite la compréhension et l'implémentation pour les développeurs. ([owasp.org][2])

## Ce qu'il faut retenir pour un développeur / un auditeur

* La 2025 invite à **s'ouvrir sur la sécurité de toute la chaîne logicielle** — pas seulement le code que l'on écrit, mais les dépendances, l'infrastructure, le processus de build et déploiement.

* Il faut prêter attention à **la gestion des erreurs et des cas imprévus** — un bon traitement des exceptions, des retours d'erreur sécurisés et un “fail-safe” sont désormais explicitement reconnus comme un risque majeur.

* Les **configurations** restent un point faible et doivent être traitées avec rigueur (automatisation, hardening, vérifications régulières).

* Les vulnérabilités « classiques » (injection, crypto, etc.) restent importantes, mais elles coexistent maintenant avec des risques plus modernes, plus systémiques.

## Réduire les vulnérabilités : principes généraux

Les **10 vulnérabilités majeures** de l'OWASP sont plus ou moins simples à contrer, mais nécessitent une prise de conscience permanente : tout code, tout serveur, toute API **peut contenir une faille**.

Quelques pistes pour les réduire :

### 1. Prévenir

En entreprise, sécuriser commence par **programmer correctement** :

* rédaction et application de **guides de bonnes pratiques**,

* mise en place d'une **assurance qualité** et de processus de développement structurés.

  (voir : fiches récapitulatives sur les méthodes de développement)

### 2. Protéger en réduisant la surface d'attaque

La programmation orientée objet aide à **isoler** les composants et réduire l'exposition.

On applique également des techniques de **durcissement (hardening)** pour limiter l'accès aux services et restreindre les privilèges.

### 3. Valider

De nombreux outils d'analyse automatique permettent d'évaluer et critiquer le code.

L'exemple utilisé en cours : **SonarQube** (audit, analyse, preuve).

S'ajoutent :

* les **tests d'intrusion** (pentests),

* les revues manuelles,

* les tests de charge et de comportement.

### 4. Mettre les autres au travail : les CTF

Les **Capture The Flag (CTF)** proposent des systèmes volontairement vulnérables, accompagnés de scénarios et d'indices.

Le but : trouver un **flag**, c'est-à-dire un secret caché dans le système.

Ils permettent :

* d'exercer sa capacité à exploiter des failles,

* de comprendre les erreurs courantes,

* de progresser de façon ludique.

Exemple : **Root-Me**

## À suivre : détail des différentes vulnérabilités OWASP

Les exemples fournis dans la suite correspondent aux vulnérabilités OWASP les plus susceptibles d'apparaître dans l'étude de cas **E6**.

Chaque point du Top 10 fait l'objet d'une fiche dédiée :

* **[A01 – Broken Access Control](OWASP/Fiche3-OWASP-A01-2025.md)**

* **[A02 – Security Misconfiguration](OWASP/Fiche3-OWASP-A02-2025.md)**

* **[A03 – Software Supply Chain Failures](OWASP/Fiche3-OWASP-A03-2025.md)**

* **[A04 – Insecure Design](OWASP/Fiche3-OWASP-A04-2025.md)**

* **[A05 – Vulnerable and Outdated Components](OWASP/Fiche3-OWASP-A05-2025.md)**

* **[A06 – Cryptographic Failures](OWASP/Fiche3-OWASP-A06-2025.md)**

* **[A07 – Authentication Failures](OWASP/Fiche3-OWASP-A07-2025.md)**

* **[A08 – Software or Data Integrity Failures](OWASP/Fiche3-OWASP-A08-2025.md)**

* **[A09 – Logging & Alerting Failures](OWASP/Fiche3-OWASP-A09-2025.md)**

* **[A10 – Mishandling of Exceptional Conditions](OWASP/Fiche3-OWASP-A10-2025.md)**

# Bloc 3 – Vulnérabilités des SI

## Fiche 3 : Sécurité d'un service web – OWASP

## [A01:2025 – Broken Access Control (Contrôle d'accès défaillant)](https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/)

Les fonctions liées à l'authentification et à la gestion de session sont souvent mal implémentées, ce qui peut permettre à un attaquant de compromettre des mots de passe, des clés ou des jetons de session, ou d'exploiter d'autres failles pour prendre l'identité d'un utilisateur, temporairement ou définitivement.

Il est important de distinguer **authentification** et **autorisation**. L'authentification (qui vous êtes) vérifie l'identité d'un utilisateur, tandis que l'autorisation (ce que vous êtes autorisé à faire) contrôle l'accès aux ressources en fonction de cette identité.

![fig1](../ficheowasp-img/fig1.jpg)

Dans ce paragraphe, l'attention porte sur l'autorisation. Pour l'authentification, voir [A07 – Identification et faiblesses d'authentification](Fiche3-OWASP-A07-2025.md).

Une restriction d'accès mal implémentée peut permettre à un attaquant d'accéder à des fonctionnalités ou des données non autorisées, telles que les comptes d'autres utilisateurs, des fichiers sensibles ou des droits d'accès non légitimes.

### Exploitation

L'autorisation est le processus qui permet de décider si une demande d'accès à une ressource particulière doit être acceptée ou refusée. Elle comprend les règles qui déterminent quelles fonctionnalités et données un utilisateur peut utiliser, garantissant la cohérence des droits après authentification.

Les applications Web doivent contrôler les privilèges des utilisateurs et permettre aux administrateurs de gérer les règles de contrôle d'accès. Les attaques les plus fréquentes incluent :

#### Accès aux pages d'administration

Les fonctions d'administration doivent être accessibles uniquement via les interfaces prévues pour les administrateurs. Les URL classiques à protéger incluent, par exemple :

* `https://target.com/admin`

* `https://target.com/administrator`

* `https://target.com/web_admin`

* `https://target.com/wp-admin`

Les attaquants peuvent utiliser des techniques de force brute ou analyser le fichier `robots.txt` pour identifier des pages sensibles. Ces pratiques exposent des failles de conception de sécurité de base.

#### Traversée de répertoires et inclusion de fichiers

Certaines applications manipulent des fichiers de manière régulière (ex : cache Symfony). Un manque de validation correcte des entrées peut permettre à un attaquant de lire ou écrire des fichiers normalement inaccessibles.

### Comment se prémunir des risques

La conception d'un contrôle d'accès efficace repose sur une évaluation des risques pour identifier les menaces et les vulnérabilités spécifiques. Comme il s'agit d'un domaine complexe et dynamique, les décisions humaines restent essentielles.

#### Listes de contrôle d'accès (ACL)

Les ACL permettent de définir les droits des utilisateurs ou des groupes sur des fichiers ou ressources spécifiques. Elles empêchent l'accès non autorisé à des fichiers sensibles ou à des services critiques (ex : interdiction d'accès SSH depuis une DMZ publique).

#### Contrôle d'accès basé sur les rôles (RBAC)

Le RBAC attribue des droits d'accès selon les rôles et responsabilités d'un utilisateur au sein de l'organisation. La définition des rôles se base sur l'analyse des objectifs et de la structure organisationnelle et doit être alignée avec la politique de sécurité.

![role-based-access-control-rbac-example](ficheowasp-img/role-based-access-control-rbac-example.png)

Exemple : dans un établissement médical, médecins, infirmiers et patients ont des droits différents selon leurs fonctions et le type de transactions autorisées. RBAC est efficace si le nombre de rôles est suffisant pour refléter correctement les besoins, mais peut devenir complexe à gérer.

# Bloc 3 – Vulnérabilités des SI

## Fiche 3 : Sécurité d'un service web – OWASP

## [A02 – Security Misconfiguration (Mauvaise configuration de sécurité)](https://owasp.org/Top10/2025/A02_2025-Security_Misconfiguration/)

La mauvaise configuration de sécurité se produit lorsque les paramètres des applications, serveurs ou infrastructures ne sont pas correctement définis. Cela peut laisser des failles exploitables par des attaquants. Une application devient vulnérable si elle :

* n'a pas été durcie (*hardening*),

* expose des fonctionnalités inutiles ou des privilèges excessifs,

* maintient des comptes ou services par défaut actifs,

* ne configure pas correctement les fonctionnalités de sécurité comme TLS, CORS ou les headers HTTP.

Les exemples concrets ne manquent pas : un serveur Apache ou Nginx exposant `/server-status`, une API REST renvoyant des traces de code détaillées, ou des en-têtes HTTP révélant le type et la version du serveur facilitent les attaques ciblées. 

Les comptes administrateurs par défaut (`admin/admin`), les ports ouverts inutilement (FTP, Telnet) et les interfaces de test laissées en production (phpMyAdmin, Jenkins) sont également des vecteurs d'attaque classiques.

Les permissions excessives posent aussi problème : fichiers accessibles en écriture à tous (`chmod 777`), utilisateurs finaux avec des droits d'administrateur par défaut, ou endpoints sensibles exposés publiquement. Dans le cloud et les environnements conteneurisés, des buckets S3 publics (espace de stockage dans Amazon Web Services (AWS)), des images Docker contenant des secrets, etc.

### Prévention et bonnes pratiques

* **Durcissement et nettoyage** : désactiver les services inutiles, mettre à jour logiciels et dépendances, supprimer les comptes par défaut.

* **Configuration sécurisée** : activer HTTPS/TLS correctement, configurer les cookies sécurisés, limiter l'accès aux endpoints sensibles.

* **Audit et surveillance** : scanner régulièrement les serveurs et applications avec des outils comme Nessus, OpenVAS ou OWASP ZAP, et mettre en place la journalisation et les alertes.

* **Exemple concret** : remplacer un compte admin par défaut, restreindre l'accès à `/phpmyadmin` à certaines adresses IP, supprimer les endpoints de debug en production et rendre privés les buckets S3 avec des règles strictes de lecture/écriture.

La mauvaise configuration de sécurité reste une vulnérabilité courante car elle peut affecter tous les niveaux du système. Une approche globale combinant durcissement, configuration sécurisée et surveillance continue est essentielle pour réduire les risques.

# Bloc 3 – Vulnérabilités des SI

## Fiche 3 : Sécurité d'un service web – OWASP

## [A03 – Software Supply Chain Failures (Défaillances de la chaîne logistique logicielle)](https://owasp.org/Top10/2025/A03_2025-Software_Supply_Chain_Failures/)

La vulnérabilité **Software Supply Chain Failures** concerne les risques liés à l'ensemble de la chaîne de développement et de livraison d'un logiciel. Une application moderne ne se limite pas à son propre code : elle utilise des bibliothèques, des dépendances, des frameworks, et des services tiers. Si l'un de ces composants est compromis ou mal configuré, l'application finale devient vulnérable, même si son code interne est sécurisé.

### Exemples concrets

Un exemple classique est celui des **bibliothèques open source compromises**. Parfois, des attaquants insèrent du code malveillant dans des packages populaires sur des registres comme **npm**, **PyPI** ou **Maven Central**. Lorsqu'un développeur installe ces packages, le code malveillant peut :

* voler des informations sensibles (mots de passe, clés API),

* créer des portes dérobées,

* exécuter des actions à l'insu de l'utilisateur ou du serveur.

Un autre exemple concerne les **scripts de build ou CI/CD compromis**. Si un pipeline de compilation récupère automatiquement du code ou des packages depuis des sources non sécurisées, un attaquant peut injecter du code malveillant qui sera intégré dans toutes les versions distribuées du logiciel.

Les **services tiers** représentent également un point critique. Une API externe compromise ou mal configurée peut introduire des vulnérabilités dans l'application qui l'utilise. Par exemple, un service de paiement dont le SDK est compromis peut permettre des transactions frauduleuses ou l'exfiltration de données de carte bancaire.

### Comment se prémunir ?

La prévention des défaillances de la chaîne logistique repose sur plusieurs bonnes pratiques :

* **Vérification des dépendances** : utiliser des outils pour scanner les packages pour détecter les vulnérabilités connues et vérifier leur intégrité. Exemples : **Snyk**, **Dependabot**, **OWASP Dependency-Check**.

* **Signer et vérifier les packages** : privilégier les packages signés cryptographiquement et vérifier les signatures avant intégration.

* **Contrôle des versions** : éviter d'utiliser des versions obsolètes ou non maintenues des bibliothèques et frameworks.

* **Audit des pipelines CI/CD** : sécuriser les scripts de build et les environnements d'intégration continue, limiter les permissions et vérifier la provenance de tout code injecté automatiquement.

* **Segmentation des privilèges** : limiter les droits des services tiers pour qu'une compromission éventuelle n'affecte qu'une partie minimale du système.

### Exemple pratique

Dans une application web, si le projet utilise un package npm pour la génération de PDF, il est recommandé de :

* vérifier la version et l'intégrité du package,

* surveiller les alertes de vulnérabilité,

* exécuter le build dans un environnement isolé,

* restreindre les droits de ce package pour qu'il ne puisse pas accéder aux données sensibles ou au réseau.

La sécurité de la chaîne logistique est un enjeu critique car **la compromission d'un composant tiers peut affecter l'ensemble du système**, même si le code principal de l'application est sûr. Les équipes doivent donc adopter une approche proactive de surveillance, d'audit et de contrôle des dépendances et services externes utilisés.