OWASP Top 10 : les vérifier sur son propre code

Vérifier le contrôle d’accès et l’authentification dans son code

Le OWASP Top 10 sert de repère pour examiner les risques applicatifs, mais il devient utile lorsque l’équipe le relie à ses routes, ses traitements et ses tests. L’édition 2021 reste une référence de base ; les pratiques récentes renforcent notamment l’analyse de code, la chaîne d’approvisionnement et les contrôles intégrés au développement.

Prenons l’exemple fictif d’une petite plateforme de réservation. Une personne connectée peut modifier son profil, mais ne devrait jamais pouvoir changer celui d’un autre client en remplaçant simplement un identifiant dans l’adresse de la requête. Ce scénario permet de tester concrètement l’autorisation, plutôt que de se limiter à vérifier qu’une page de connexion existe.

Tester les autorisations sur chaque ressource

Dans cette catégorie de risque, l’application reconnaît l’utilisateur sans toujours vérifier ce qu’il a le droit de faire. Une route qui accepte un identifiant transmis par le navigateur et modifie directement l’objet correspondant peut exposer des données ou autoriser des changements non permis.

Pour contrôler ce comportement, créez deux comptes de test et identifiez une action qui modifie une ressource personnelle. Avec le jeton du premier compte, essayez d’accéder à une ressource appartenant au second ; la réponse doit refuser l’opération, même si l’identifiant est valide.

Un correctif robuste vérifie l’identité et le rôle au plus près de la décision, puis applique la même politique à chaque point d’entrée concerné. Une vérification centralisée dans un middleware ou une couche de politiques limite les oublis, tandis qu’un test automatisé protège le comportement lors des changements futurs.

Dans l’exemple de la plateforme, l’équipe peut aussi vérifier qu’un administrateur possède uniquement les permissions nécessaires à sa fonction. Le contrôle d’accès ne consiste donc pas à ajouter une condition isolée : il faut décrire qui peut lire, modifier ou supprimer chaque type de ressource.

Listez d’abord les opérations sensibles, puis associez chacune à un rôle et à une règle explicite. Cette cartographie rend la revue plus concrète et aide à repérer les routes qui s’appuient à tort sur une valeur envoyée par le navigateur.

Vérifications des autorisations :

• Comparer les droits de deux comptes de test
• Modifier les identifiants dans les requêtes de test
• Vérifier les refus sur les opérations interdites
• Tester aussi les rôles privilégiés et leurs limites

Examiner les sessions et les secrets d’authentification

Une authentification efficace ne s’arrête pas à la validation d’un mot de passe. Les jetons trop durables, les sessions impossibles à révoquer et les secrets déposés dans le dépôt de code peuvent prolonger l’accès d’un compte compromis.

Selon l’OWASP Cheat Sheet Series, les mécanismes d’authentification doivent être conçus avec une gestion prudente des sessions et des informations sensibles. En pratique, testez l’expiration d’un jeton, son invalidation après une déconnexion et le renouvellement des jetons d’accès lorsqu’un mécanisme de rafraîchissement est utilisé.

Les mots de passe ne doivent pas être conservés en clair ni protégés par une empreinte cryptographique rapide conçue pour d’autres usages. Les bibliothèques reconnues de hachage de mots de passe, comme Argon2 ou bcrypt, sont adaptées à ce besoin lorsqu’elles sont correctement configurées.

Ajoutez également la recherche de secrets codés en dur dans les contrôles de pré-fusion. Une clé visible dans un ancien historique peut rester exploitable après sa suppression du fichier courant : la rotation de la clé et la vérification des journaux d’accès restent alors nécessaires.

Les tests ciblés établissent si les règles fonctionnent réellement, tandis que les contrôles automatiques préviennent les régressions courantes. Une fois les identités et les autorisations vérifiées, l’attention peut se déplacer vers les données reçues et les traitements qui les interprètent.

Élément testé	Essai pratique	Résultat attendu
Accès à un profil	Un compte tente de modifier le profil d’un autre	Refus sans changement de données
Expiration du jeton	Réutiliser un jeton après son échéance	Rejet et demande de reconnexion
Révocation de session	Réutiliser une session après déconnexion	Session invalidée selon la politique
Secret dans le dépôt	Exécuter un détecteur de secrets sur le projet	Aucun secret exploitable dans le code

Repérer l’injection, les erreurs de conception et les mauvaises configurations

Après les contrôles d’identité, l’examen porte sur la manière dont l’application traite les entrées et expose ses fonctions. Une valeur anodine dans un formulaire peut devenir dangereuse si le programme la transforme sans précaution en requête, commande ou adresse à consulter.

Rechercher les injections dans les requêtes et commandes

L’injection apparaît lorsqu’une donnée contrôlée par l’utilisateur est interprétée comme une partie de la syntaxe d’une requête ou d’une commande. Une concaténation SQL construite avec un identifiant reçu dans l’URL constitue un exemple classique ; le défaut tient à la confusion entre données et instructions.

Pour un premier contrôle, repérez les requêtes composées par assemblage de chaînes et retracez l’origine de chaque valeur. Une recherche textuelle peut aider à trouver des appels sensibles, mais elle ne remplace pas l’analyse du flux de données ni l’exécution d’un test dans un environnement autorisé.

La correction habituelle consiste à employer des requêtes paramétrées, qui transmettent séparément les valeurs et la structure de la requête. Il faut aussi éviter de croire qu’un filtrage artisanal suffit : les règles d’échappement varient selon le contexte et restent faciles à appliquer incorrectement.

Selon l’OWASP Foundation, l’injection figure parmi les risques majeurs que les équipes doivent traiter dans leur programme de sécurité applicative. Des règles SAST peuvent signaler des constructions suspectes, tandis qu’un test dynamique observe les réponses de l’application en fonctionnement.

Un scan dynamique sur une plateforme de préproduction aide à trouver des comportements qui n’apparaissent pas dans l’analyse statique. Il doit toutefois être cadré : cible autorisée, données de test, fenêtre d’exécution connue et traitement des alertes avant toute mise en production.

Évaluer la conception et la configuration sécurisée

Une faille de conception peut exister même lorsque chaque fonction semble correctement codée. Par exemple, permettre le dépôt d’un fichier puis son exécution depuis un répertoire accessible transforme une décision d’architecture en risque, indépendamment de la qualité du formulaire.

Un examen de conception pose des questions concrètes : où les fichiers sont-ils stockés, quels types sont admis, quel processus les traite et avec quels privilèges ? La réponse doit inclure une validation adaptée, un stockage séparé des chemins d’exécution et des tests qui confirment les restrictions attendues.

Les erreurs de configuration ouvrent d’autres portes : interface de débogage visible, service inutile exposé, autorisation cloud trop large ou compte par défaut conservé. Une configuration sécurisée commence par des valeurs de référence contrôlées et par la suppression des fonctions qui ne servent pas.

Selon le NIST, le SSDF encourage l’intégration de pratiques de développement sécurisé dans le cycle de vie logiciel. Une équipe peut traduire cette approche en revues d’architecture, exigences documentées, scans d’infrastructure et vérifications automatiques des réglages de production.

Contrôles d’architecture et de configuration :

• Inventorier les services et interfaces exposés
• Vérifier les permissions des rôles cloud
• Tester les limites de dépôt et de traitement des fichiers
• Désactiver les pages de débogage en production

Les outils d’analyse d’infrastructure, comme Checkov ou tfsec, peuvent signaler des configurations risquées selon les règles prises en charge et la version utilisée. Les résultats doivent être examinés par l’équipe : un avertissement n’établit pas à lui seul la présence d’une faille exploitable.

Risque examiné	Signal dans le code ou l’environnement	Contrôle recommandé
Injection	Requête construite par concaténation	Requêtes paramétrées et tests ciblés
Défaut de conception	Fichier téléversé dans un emplacement exécutable	Stockage isolé et tests de contraintes
Mauvaise configuration	Service ou mode de débogage exposé	Scan de configuration et vérification en production
Privilèges excessifs	Compte ou rôle doté de droits inutiles	Revue des permissions selon le moindre privilège

La validation des entrées et des paramètres réduit une partie du risque, mais une application dépend aussi du code qu’elle n’a pas écrit. Les bibliothèques, images de conteneur et artefacts de livraison méritent donc un contrôle distinct.

Auditer les dépendances vulnérables et la chaîne d’approvisionnement

Les vérifications du code ne couvrent pas les composants externes qui entrent dans une application. Une bibliothèque obsolète, une image de conteneur fragile ou un artefact remplacé après sa construction peuvent modifier le risque sans changement visible dans les fichiers métier.

Inventorier les composants et traiter les alertes

Un audit de sécurité des dépendances commence par un inventaire fiable des paquets directs et indirects. Les outils d’analyse de composition logicielle comparent cet inventaire aux vulnérabilités connues ; leur résultat doit ensuite être relié aux versions réellement déployées et aux fonctions utilisées.

Générer une SBOM à chaque construction fournit une liste structurée des composants livrés. CycloneDX et SPDX sont deux formats utilisés pour représenter ces informations ; le choix doit tenir compte des outils déjà présents et des attentes des partenaires ou des équipes opérationnelles.

Selon la CISA, les SBOM constituent un élément important de la visibilité sur les composants logiciels. Une liste ne corrige cependant rien par elle-même : l’équipe doit attribuer les alertes, évaluer leur gravité dans son contexte, appliquer une mise à jour ou documenter une mesure compensatoire.

Une dépendance déclarée vulnérable n’implique pas automatiquement que l’application est exploitable. Il faut vérifier si la version concernée est présente, si le chemin vulnérable est accessible et si une version corrigée peut être intégrée sans introduire de régression.

Une règle utile dans la chaîne d’intégration signale les paquets non maintenus ou les vulnérabilités de gravité élevée, puis suit une politique d’exception explicite. Bloquer indistinctement chaque alerte peut provoquer des contournements ; laisser passer toutes les alertes rend le contrôle inutile.

Protéger l’intégrité des builds et des artefacts

La sécurité de la chaîne d’approvisionnement concerne également la provenance : quelle source a produit l’artefact, avec quel processus et pour quelle révision du code ? Une signature aide le système destinataire à vérifier qu’un artefact correspond à une identité ou à un processus attendu.

Des outils de l’écosystème Sigstore, notamment cosign, peuvent signer et vérifier des artefacts selon leur configuration. Une équipe doit protéger les clés ou les identités de signature, définir la politique de vérification et refuser le déploiement lorsqu’une preuve attendue manque.

Une SBOM associée à un artefact signé améliore la traçabilité, mais ne garantit pas à elle seule que chaque composant est sûr. Il faut aussi protéger les comptes de construction, limiter les permissions des tâches automatisées et examiner les changements apportés aux dépendances lors des revues.

Mesures pour la chaîne logicielle :

• Produire une SBOM pour chaque build livrable
• Analyser les dépendances directes et indirectes
• Signer les artefacts selon une politique vérifiable
• Limiter les droits des comptes et tâches de construction

Les assistants de programmation peuvent accélérer l’écriture, mais le code suggéré doit être traité comme tout autre code reçu d’une source externe. Le développeur vérifie les choix cryptographiques, les contrôles d’autorisation, les dépendances ajoutées et la présence éventuelle de secrets avant d’accepter la modification.

Pour garder une trace utile, la revue associe chaque alerte à une décision : corriger, mettre à jour, réduire l’exposition ou accepter temporairement le risque avec un responsable et une échéance. Cette discipline évite que la liste de vulnérabilités devienne un inventaire oublié.

Tester les journaux, les requêtes réseau et les risques à l’exécution

Une application peut respecter des contrôles de conception tout en révélant des faiblesses lorsqu’elle fonctionne. Les tests de sécurité en exécution complètent l’analyse de code en observant les réponses, les interactions réseau et les événements que l’application enregistre réellement.

Détecter les requêtes serveur dangereuses

Une vulnérabilité de type SSRF apparaît lorsque le serveur récupère une adresse fournie par l’utilisateur sans restrictions suffisantes. L’attaquant peut alors tenter de faire contacter au serveur des destinations internes, ce qui expose parfois des interfaces d’administration ou des métadonnées de service cloud.

Pour examiner cette fonction, identifiez les champs qui acceptent une URL, comme l’import d’image ou la génération d’un aperçu. En environnement de test, vérifiez que l’application n’accède qu’aux hôtes autorisés et qu’elle refuse les adresses locales, privées ou réservées aux services internes.

Un filtrage fiable ne se limite pas à comparer le texte de l’URL. L’application doit contrôler la destination après résolution, traiter les redirections avec prudence et appliquer des règles de sortie réseau qui empêchent les connexions non nécessaires.

Selon les recommandations de sécurité applicative de l’OWASP, il faut limiter les entrées et les opérations qui permettent à un serveur d’interroger des ressources externes. Les règles réseau constituent ici une seconde barrière : elles réduisent l’impact si une validation applicative échoue.

Vérifier la journalisation et les alertes

Des journaux incomplets rendent difficile la compréhension d’un incident. L’application devrait enregistrer les événements utiles, par exemple un échec répété d’authentification ou une modification sensible, sans conserver de mots de passe, jetons ou secrets dans les messages.

Les journaux structurés facilitent le rapprochement des événements entre services et leur analyse par une plateforme centralisée. Il faut toutefois contrôler les droits d’accès aux journaux, leur durée de conservation et les risques de fuite de données personnelles qu’ils pourraient contenir.

Ajoutez des tests d’acceptation qui déclenchent un événement attendu, puis vérifiez sa présence dans le système de collecte. Pour les alertes, le test doit confirmer qu’un seuil ou une règle produit une notification exploitable, et non simplement qu’un fichier journal a été créé.

OWASP ZAP propose des contrôles dynamiques qui peuvent être automatisés sur une application de test. Un scan de base repère certains signaux, mais ne prouve ni l’absence de vulnérabilité ni la couverture de tous les parcours fonctionnels.

Pour une équipe comme celle de la plateforme de réservation, le résultat utile associe chaque constat à une route, une preuve reproductible et une correction vérifiée. Cette méthode transforme le rapport technique en travail priorisé, au lieu d’accumuler des alertes sans propriétaire.

Contrôles à l’exécution :

• Limiter les destinations accessibles depuis le serveur
• Tester les parcours sensibles en environnement de préproduction
• Vérifier les journaux sans y exposer de secrets
• Confirmer le déclenchement des alertes prévues

Ces essais mettent en évidence ce qu’un contrôle statique ne voit pas toujours : les réponses réelles, la configuration active et les interactions entre composants. L’étape suivante consiste à intégrer ces vérifications sans ralentir inutilement chaque livraison.

Intégrer les vérifications OWASP Top 10 dans la CI/CD

Une revue ponctuelle repère les défauts présents au moment de l’audit, mais elle ne protège pas les changements suivants. Des contrôles intégrés au pipeline permettent de vérifier régulièrement le code, les dépendances, la configuration et l’application en fonctionnement.

Construire une chaîne de contrôles proportionnée

Commencez par une analyse statique à chaque demande de fusion, avec des règles adaptées aux langages et aux risques de l’application. Semgrep ou Sonar peuvent contribuer à repérer certaines erreurs, mais la configuration des règles, les faux positifs et les résultats non couverts demandent une revue humaine.

Ajoutez ensuite une analyse de composition des dépendances et la génération d’une SBOM au moment de la construction. Une politique explicite précise quelles alertes bloquent une livraison, qui peut approuver une exception et comment cette exception sera réexaminée.

Les tests dynamiques peuvent s’exécuter sur un environnement temporaire ou de préproduction, après le déploiement de la version candidate. OWASP ZAP fournit des options d’automatisation ; les tests doivent rester limités à des systèmes maîtrisés et à des données sans enjeu réel.

Enfin, signez les artefacts et vérifiez leur signature avant le déploiement. Cette étape relie le livrable à son processus de construction ; elle doit être accompagnée de contrôles sur l’identité de signature et sur les permissions des comptes utilisés par le pipeline.

Étapes du pipeline applicatif :

• Analyser le code lors des demandes de fusion
• Contrôler les dépendances et produire la SBOM
• Construire puis signer les artefacts livrables
• Exécuter des tests dynamiques sur une cible autorisée
• Vérifier les preuves avant le déploiement

Transformer les résultats en corrections suivies

Un pipeline efficace ne se mesure pas au nombre d’outils affichés dans ses journaux. Il se mesure à la capacité de l’équipe à comprendre un résultat, décider d’une action et vérifier que le défaut ne réapparaît pas après correction.

Associez chaque constat à un responsable, une priorité et une preuve de résolution. Une injection corrigée par requête paramétrée doit être couverte par un test ; un défaut d’autorisation doit être vérifié pour plusieurs rôles ; une bibliothèque mise à jour doit être confirmée dans l’inventaire livré.

Les règles de blocage doivent tenir compte de la gravité, de l’exposition et des conséquences pour les utilisateurs. Un contrôle très strict mais régulièrement contourné protège moins qu’une règle ciblée, comprise par les développeurs et accompagnée d’un chemin rapide pour traiter les alertes légitimes.

La formation complète ces outils. Des ateliers fondés sur les routes et les composants du produit aident les développeurs à reconnaître les erreurs récurrentes, tandis que les revues de code posent des questions concrètes sur les autorisations, la validation des entrées et la protection des données.

Selon le NIST, le SSDF inscrit les pratiques de développement sécurisé dans le cycle de vie logiciel plutôt que de les réserver à une vérification finale. Dans cette logique, l’OWASP Top 10 sert de grille de travail : chaque risque devient un test, une règle ou une décision documentée dans le dépôt.

Gardez une vue simple des contrôles activés, de leurs responsables et de leurs limites connues. Une équipe peut alors montrer ce qu’elle vérifie réellement, corriger les lacunes les plus importantes et adapter ses règles lorsque l’architecture ou les menaces évoluent.

Pour une première mise en œuvre, reliez chaque catégorie examinée à une partie identifiable du projet : route, bibliothèque, configuration ou flux de déploiement. Cette correspondance rend l’audit reproductible et permet de vérifier les corrections au fil des modifications, sans réduire la sécurité à une liste de cases cochées.