Top 10 OWASP pour débuter : comprendre les risques d’une application web

Une application web peut fonctionner correctement tout en exposant des faiblesses importantes : un utilisateur accède à une donnée qui ne lui appartient pas, une configuration laisse un service ouvert ou une entrée mal contrôlée modifie le comportement du site. Le Top 10 OWASP sert de grille de lecture pour comprendre ces risques et organiser les premières vérifications.

Ce référentiel ne remplace ni un audit complet ni une expertise en sécurité. Il fournit plutôt un vocabulaire commun et une liste de priorités pour les développeurs, les responsables de site et les petites équipes. Les catégories peuvent évoluer selon les éditions du référentiel ; il faut donc toujours vérifier la version utilisée dans un projet.

À quoi sert réellement le Top 10 OWASP ?

OWASP est une communauté qui publie des ressources ouvertes consacrées à la sécurité des applications web. Son Top 10 regroupe les familles de vulnérabilités et de mauvaises pratiques observées fréquemment dans les projets web. Il ne s’agit pas d’un classement de dix failles isolées à rechercher mécaniquement, mais d’un cadre pour poser les bonnes questions.

Pour une petite entreprise, cette grille est utile à trois moments :

• avant le développement, pour prévoir des règles de conception et de gestion des accès ;
• pendant la réalisation, pour vérifier les contrôles ajoutés au code et à l’infrastructure ;
• avant la mise en production, pour repérer les secrets exposés, les réglages dangereux et les dépendances obsolètes.

Le Top 10 ne donne pas automatiquement la gravité d’un problème dans votre contexte. Une faiblesse théorique peut être peu exploitable sur un site isolé, tandis qu’un défaut d’autorisation peut devenir critique si l’application traite des données clients ou des fonctions d’administration.

Les grandes familles de risques à connaître

Les intitulés exacts dépendent de l’édition consultée et certaines catégories peuvent être regroupées ou renommées. Les familles suivantes couvrent toutefois les principaux sujets qu’un débutant doit savoir reconnaître.

Contrôle d’accès défaillant

Le contrôle d’accès détermine ce qu’un utilisateur a le droit de consulter ou de modifier. Un problème apparaît lorsque l’application se contente de masquer un bouton dans l’interface sans vérifier l’autorisation côté serveur.

Exemple : un compte standard ne voit pas le menu d’administration, mais peut tout de même appeler directement l’adresse d’une fonction réservée. La vérification doit donc être appliquée à chaque action sensible, avec une règle claire pour chaque rôle.

Les contrôles à examiner sont notamment les suivants :

• un utilisateur peut-il consulter l’objet d’un autre utilisateur en modifiant un identifiant ?
• les actions réservées aux administrateurs sont-elles protégées côté serveur ?
• les droits sont-ils retirés lorsqu’un compte change de rôle ou est désactivé ?

Erreurs d’authentification et de gestion des sessions

L’authentification concerne la preuve de l’identité ; la session permet ensuite de conserver cette identité entre les requêtes. Une protection insuffisante peut venir d’un mot de passe mal géré, d’une session trop longue, d’une absence de limitation après plusieurs échecs ou d’une réinitialisation de compte mal conçue.

Une base saine comprend des mots de passe stockés avec un mécanisme de hachage adapté, une authentification multifacteur lorsque le risque le justifie, des sessions invalidées après déconnexion et une procédure de récupération qui ne révèle pas d’informations inutiles.

Injection de données non contrôlées

Une injection se produit lorsqu’une donnée fournie par l’utilisateur est interprétée comme une instruction par un autre système. Les bases de données, les moteurs de recherche, les interpréteurs ou certaines commandes système peuvent être concernés.

Le principe de défense est de séparer les données des instructions. En pratique, cela passe par les requêtes paramétrées, la validation des formats attendus et l’utilisation prudente des fonctions qui construisent dynamiquement une commande. Échapper une chaîne au dernier moment ne remplace pas une conception correctement séparée.

Conception non sécurisée

Certains problèmes apparaissent avant même l’écriture du code. Une application peut, par exemple, permettre des transferts sans limite, accepter une modification sensible sans confirmation ou ne prévoir aucun scénario de récupération après une compromission.

La sécurité doit être discutée au moment de définir les règles métier. Pour chaque fonctionnalité importante, décrivez les acteurs, les données manipulées, les actions autorisées et les conséquences d’un abus. Cette étape évite de dépendre uniquement d’un correctif ajouté à la fin du projet.

Configuration de sécurité incorrecte

Une application peut être fragilisée par des réglages par défaut, des messages d’erreur trop détaillés, des interfaces d’administration accessibles publiquement ou des en-têtes de sécurité absents. Le code n’est pas toujours responsable : le serveur web, le CMS, la base de données et les services cloud font partie de la surface à protéger.

Avant la mise en ligne, supprimez les comptes inutiles, désactivez les fonctions de test, remplacez les identifiants par défaut et vérifiez que les informations techniques ne sont pas affichées aux visiteurs. Les environnements de développement et de production doivent aussi utiliser des configurations séparées.

Composants obsolètes ou vulnérables

Une bibliothèque, une extension, un thème ou une image système peut introduire un risque connu. Plus un projet accumule de dépendances non suivies, plus il devient difficile de savoir quelles versions sont utilisées et lesquelles doivent être corrigées.

Un inventaire simple constitue un bon début : notez les composants, leur version, leur responsable et leur méthode de mise à jour. Les mises à niveau doivent être testées, mais les repousser indéfiniment augmente l’exposition. Supprimez également les extensions inutilisées au lieu de les laisser désactivées.

Défauts de chiffrement et protection insuffisante des données

Les données sensibles doivent être protégées selon leur usage. Le chiffrement pendant le transport protège les échanges entre le navigateur et le serveur ; il ne suffit pas à sécuriser une base de données, une sauvegarde ou une clé stockée dans le code.

Commencez par identifier les données réellement sensibles, limitez leur collecte et contrôlez qui peut les consulter. Les secrets d’application ne doivent pas être placés dans un dépôt public ou dans un fichier envoyé au navigateur. La gestion des clés mérite une attention distincte : une donnée chiffrée n’est pas correctement protégée si sa clé est conservée au même endroit sans contrôle.

Défaillances liées à l’intégrité des logiciels et des données

Une application dépend souvent de paquets, de scripts, d’images de conteneurs ou de processus de déploiement. Si leur provenance n’est pas contrôlée, une modification non autorisée peut être introduite avant même l’exécution du site.

Les contrôles utiles comprennent la revue des changements, la protection des branches, la limitation des droits dans la chaîne de déploiement et la vérification des dépendances téléchargées. Pour une petite équipe, l’objectif n’est pas de construire un dispositif complexe, mais d’éviter qu’une seule personne ou qu’un seul compte compromis puisse modifier et publier tout le projet sans vérification.

Journalisation et surveillance insuffisantes

Sans journaux exploitables, il est difficile de comprendre ce qui s’est passé après un incident. Les événements pertinents incluent les connexions inhabituelles, les changements de droits, les échecs répétés, les modifications de configuration et les actions d’administration.

Un journal utile indique au minimum quand l’événement a eu lieu, quel compte ou service est concerné et quelle action a été effectuée. Évitez cependant d’y enregistrer des mots de passe, des jetons de session ou des données personnelles inutiles. La surveillance doit être associée à une procédure : qui reçoit l’alerte, qui vérifie les faits et combien de temps les traces sont conservées ?

Requêtes serveur forgées et accès à des ressources internes

Certaines applications récupèrent une ressource à partir d’une adresse fournie par l’utilisateur : import d’image, aperçu d’une page ou connexion à un service externe. Si cette fonctionnalité accepte n’importe quelle destination, elle peut être détournée pour faire effectuer au serveur des requêtes qu’il ne devrait pas réaliser.

La réduction du risque passe par une liste de destinations autorisées, la limitation des protocoles acceptés, le filtrage des redirections et une séparation réseau entre l’application et les services sensibles. Cette vérification doit être faite côté serveur ; contrôler uniquement l’adresse saisie dans le navigateur ne suffit pas.

Comment utiliser cette grille sans lancer un audit offensif ?

Pour un premier diagnostic, partez d’une fonctionnalité précise plutôt que de vouloir contrôler toute l’application. Un formulaire de contact, un espace client ou une page d’administration permet de travailler sur un périmètre compréhensible.

1. Décrivez les données : que reçoit la fonctionnalité, que stocke-t-elle et qui peut les consulter ?
2. Listez les rôles : visiteur, utilisateur, éditeur, administrateur ou service automatisé.
3. Vérifiez chaque action côté serveur : lecture, création, modification, suppression et export.
4. Examinez les entrées : format attendu, taille maximale, validation et traitement par les systèmes en aval.
5. Contrôlez la configuration : mode production, secrets, messages d’erreur, droits des fichiers et dépendances.
6. Préparez la détection : événements journalisés, alertes, sauvegardes et personne chargée de réagir.

Documentez chaque constat avec quatre informations : le risque, la fonctionnalité concernée, la correction envisagée et la priorité. Cette méthode évite les listes de problèmes impossibles à traiter et facilite le suivi après correction.

Prioriser les corrections selon le contexte

La priorité dépend de l’exposition, de la facilité d’exploitation, de la valeur des données et des conséquences possibles. Un défaut touchant une interface publique et un compte administrateur ne se traite pas comme une amélioration de configuration sans impact immédiat.

Les erreurs fréquentes lors d’une première démarche

• Se limiter au classement : l’absence d’un intitulé dans une liste ne signifie pas que le risque est impossible.
• Tester uniquement l’interface : une autorisation doit rester valide même si un utilisateur modifie directement une requête.
• Corriger sans retester : une mise à jour peut modifier un comportement ; prévoyez une vérification après chaque changement important.
• Oublier les services tiers : hébergement, extensions, outils d’authentification et prestataires d’envoi font partie du périmètre.
• Conserver trop de données : réduire les informations stockées diminue aussi l’impact potentiel d’un incident.

Le Top 10 OWASP devient utile lorsqu’il transforme la sécurité en habitudes de conception, de revue et de maintenance. Pour un petit projet, mieux vaut corriger méthodiquement une fonctionnalité exposée, documenter les décisions et prévoir une nouvelle vérification que produire une liste exhaustive jamais suivie d’actions.