Rapport OWASP sur la norme de vérification de la sécurité des applications V5.0

La norme OWASP de vérification de la sécurité des applications (ASVS) définit un cadre complet d'exigences de sécurité au niveau applicatif. Il s'agit d'une référence communautaire pour la conception, le développement et la vérification de logiciels sécurisés, destinée aux architectes, développeurs, testeurs et équipes de gestion des risques.

Objectifs de la norme OWASP de vérification de la sécurité des applications (ASVS)

La version 5.0 de la norme se concentre sur les principes clés suivants :

  • Portée et orientation affinées : la norme est restructurée autour de quatre piliers (Application, Sécurité, Vérification et Norme) et met l'accent sur ce qui doit être atteint plutôt que sur des étapes prescriptives.
  • Décisions de sécurité documentées : De nouvelles méta-exigences imposent la documentation des choix de conception pour garantir la traçabilité, l'alignement et la vérifiabilité.
  • Niveaux simplifiés et accessibilité accrue : Conserve trois niveaux (L1–L3) mais clarifie leur portée : le niveau 1 fournit une résistance de base aux attaques courantes, le niveau 2 représente les bonnes pratiques standard et le niveau 3 s'applique aux systèmes critiques et à haute assurance.
  • Contenu restructuré et enrichi : Environ 350 exigences couvrent désormais 17 chapitres, avec une organisation plus claire et une correspondance avec la v4.0 pour faciliter la migration.

AppScan Enterprise Rapport sur la norme OWASP de vérification de la sécurité des applications (ASVS)

Ce rapport AppScan Enterprise sur la norme industrielle évalue votre application par rapport aux niveaux de vérification de sécurité définis dans la norme OWASP de vérification de la sécurité des applications (ASVS) V5.0.0, en vigueur depuis mai 2025.

Norme de vérification de la sécurité des applications (ASVS) :

La norme de vérification de la sécurité des applications est développée et maintenue par OWASP. Cette norme est publiée sous la licence Creative Commons Attribution ShareAlike 3.0. Pour plus d'informations, voir Pour plus d'informations, voir OWASP Application Security Verification Standard V5.0.0

Pour plus d'informations sur la sécurisation des applications web, voir HCL AppScan : Advanced Application Security Testing

Vulnérabilités du rapport sur la norme OWASP de vérification de la sécurité des applications (ASVS)

ID Nom
1.1.2 Vérifier que l'encodage et l'échappement de la sortie sont effectués soit en dernière étape avant son utilisation par l'interpréteur auquel elle est destinée, soit par l'interpréteur lui-même.
1.2.1 Vérifier que l'encodage de la sortie pour une réponse HTTP, un document HTML ou un document XML est adapté au contexte requis, par exemple par l'encodage des caractères pertinents pour les éléments HTML, les attributs HTML, les commentaires HTML, le CSS ou les champs d'en-tête HTTP, afin d'éviter de modifier la structure du message ou du document.
1.2.3 Vérifier que l'encodage ou l'échappement de la sortie est utilisé lors de la génération dynamique de contenu JavaScript (y compris JSON), afin d'éviter de modifier la structure du message ou du document (afin d'éviter les injections JavaScript et JSON).
1.2.4 Vérifier que la sélection de données ou les requêtes de base de données (par ex., SQL, HQL, NoSQL, Cypher) utilisent des requêtes paramétrées, des ORM, des frameworks d'entités, ou sont autrement protégées contre l'injection SQL et d'autres attaques par injection de base de données. Cela est également pertinent lors de l'écriture de procédures stockées.
1.2.5 Vérifier que l'application est protégée contre l'injection de commandes du système d'exploitation et que les appels au système d'exploitation utilisent des paramètres appropriés ou un encodage contextuel de la sortie en ligne de commande.
1.2.7 Vérifier que l'application est protégée contre les attaques par injection XPath en utilisant la paramétrisation des requêtes ou des requêtes précompilées.
1.3.1 Vérifier que toute entrée HTML non fiable provenant d'éditeurs WYSIWYG ou similaires est assainie à l'aide d'une bibliothèque ou d'une fonctionnalité de framework de nettoyage HTML bien connue et sécurisée.
1.3.2 Vérifier que l'application évite l'utilisation de eval() ou d'autres fonctionnalités d'exécution dynamique de code telles que Spring Expression Language (SpEL). Lorsqu'il n'y a pas d'alternative, toute entrée utilisateur incluse dans l'exécution doit être assainie avant d'être exécutée.
1.3.3 Vérifier que les données transmises à un contexte potentiellement dangereux sont assainies au préalable pour appliquer des mesures de sécurité, telles que n'autoriser que les caractères sûrs pour ce contexte et tronquer les entrées trop longues.
1.3.4 Vérifier que le contenu scriptable SVG (Scalable Vector Graphics) fourni par l'utilisateur est validé ou assaini afin de ne contenir que des balises et des attributs sûrs pour l'application, par ex. sans scripts ni foreignObject.
1.3.5 Vérifier que l'application assainit ou désactive le contenu scriptable ou de langage de modèle d'expression fourni par l'utilisateur, tel que Markdown, les feuilles de style CSS ou XSL, BBCode ou similaire.
1.3.6 Vérifier que l'application protège contre les attaques de type Server-side Request Forgery (SSRF), en validant les données non fiables par rapport à une liste d'autorisation de protocoles, domaines, chemins et ports, et en assainissant les caractères potentiellement dangereux avant d'utiliser les données pour appeler un autre service.
1.3.10 Vérifier que les chaînes de format qui pourraient être interprétées de manière inattendue ou malveillante lors de leur utilisation sont assainies avant d'être traitées.
1.3.11 Vérifier que l'application assainit les entrées utilisateur avant de les transmettre aux systèmes de messagerie pour se protéger contre l'injection SMTP ou IMAP.
1.4.1 Vérifier que l'application utilise des traitements de chaînes sûrs en mémoire, des copies mémoire plus sûres et une arithmétique de pointeurs sûre pour détecter ou prévenir les dépassements de pile, de tampon ou de tas.
1.4.2 Vérifier que des techniques de validation de signe, de plage et d'entrée sont utilisées pour prévenir les dépassements d'entiers.
1.5.1 Vérifier que l'application configure les analyseurs XML pour utiliser une configuration restrictive et que les fonctionnalités non sûres telles que la résolution d'entités externes sont désactivées pour prévenir les attaques XML eXternal Entity (XXE).
1.5.2 Vérifier que, lors de la désérialisation de données non fiables, un traitement sûr des entrées est appliqué, par exemple en utilisant une liste d'autorisation de types d'objets ou en restreignant les types d'objets définis par le client, afin de prévenir les attaques par désérialisation. Les mécanismes de désérialisation qui sont explicitement définis comme non sûrs ne doivent pas être utilisés avec des entrées non fiables.
1.5.3 Vérifier que les différents analyseurs utilisés dans l'application pour le même type de données (par ex., analyseurs JSON, analyseurs XML, analyseurs d'URL) effectuent l'analyse de manière cohérente et utilisent le même mécanisme d'encodage de caractères pour éviter des problèmes tels que les vulnérabilités d'interopérabilité JSON ou l'exploitation de comportements différents d'analyse d'URI ou de fichiers dans les attaques de type Remote File Inclusion (RFI) ou Server-side Request Forgery (SSRF).
2.2.1 Vérifier que l'entrée est validée afin de garantir le respect des exigences métier ou fonctionnelles associées à cette entrée. Cela devrait soit utiliser une validation positive fondée sur une liste autorisée de valeurs, de motifs et de plages, soit reposer sur la comparaison de l'entrée à une structure attendue et à des limites logiques selon des règles prédéfinies. Pour L1, cela peut se concentrer sur les entrées utilisées pour prendre des décisions métier ou de sécurité spécifiques. Pour L2 et au-delà, cela devrait s'appliquer à toutes les entrées.
2.2.2 Vérifier que l'application est conçue pour faire respecter la validation des entrées au niveau d'une couche de service de confiance. Bien que la validation côté client améliore la convivialité et doive être encouragée, elle ne doit pas être utilisée comme contrôle de sécurité sur lequel s'appuyer.
2.2.3 Vérifier que l'application s'assure que les combinaisons d'éléments de données associés sont raisonnables selon les règles prédéfinies.
2.3.1 Vérifier que l'application ne traite les flux de logique métier pour le même utilisateur que dans l'ordre séquentiel attendu des étapes et sans ignorer d'étapes.
2.3.2 Vérifier que les limites de la logique métier sont implémentées conformément à la documentation de l'application afin d'éviter l'exploitation de failles de logique métier.
2.4.1 Vérifier que des contrôles anti-automatisation sont en place pour protéger contre les appels excessifs aux fonctions de l'application qui pourraient entraîner une exfiltration de données, la création de données parasites, l'épuisement des quotas, le dépassement des limites de débit, un déni de service ou une surutilisation de ressources coûteuses.
2.4.2 Vérifier que les flux de logique métier exigent un délai réaliste pour une intervention humaine, empêchant les soumissions de transactions excessivement rapides.
3.2.1 Vérifier que des contrôles de sécurité sont en place pour empêcher les navigateurs d'afficher du contenu ou des fonctionnalités dans les réponses HTTP dans un contexte incorrect (par exemple, lorsqu'une API, un fichier téléversé par l'utilisateur ou une autre ressource est demandé directement). Les contrôles possibles pourraient inclure : ne pas servir le contenu à moins que les champs d'en-tête de requête HTTP (tels que Sec-Fetch-\*) n'indiquent qu'il s'agit du contexte correct, utiliser la directive sandbox du champ d'en-tête Content-Security-Policy ou utiliser le type de disposition attachment dans le champ d'en-tête Content-Disposition.
3.3.1 Vérifier que les cookies ont l'attribut 'Secure' défini, et si le préfixe '\__Host-' n'est pas utilisé pour le nom du cookie, le préfixe '__Secure-' doit être utilisé pour le nom du cookie.
3.3.2 Vérifier que la valeur de l'attribut 'SameSite' de chaque cookie est définie en fonction de l'objectif du cookie, afin de limiter l'exposition aux attaques de détournement d'interface utilisateur et aux attaques de falsification de requêtes basées sur le navigateur, communément appelées falsification de requêtes intersites (CSRF).
3.3.3 Vérifier que les cookies ont le préfixe '__Host-' pour le nom du cookie, sauf s'ils sont explicitement conçus pour être partagés avec d'autres hôtes.
3.3.4 Vérifier que si la valeur d'un cookie n'est pas destinée à être accessible aux scripts côté client (comme un jeton de session), le cookie doit avoir l'attribut 'HttpOnly' défini et la même valeur (par exemple, le jeton de session) ne doit être transmise au client que via le champ d'en-tête 'Set-Cookie'.
3.4.1 Vérifier qu'un champ d'en-tête Strict-Transport-Security est inclus dans toutes les réponses pour imposer une politique HTTP Strict Transport Security (HSTS). Une durée maximale d'au moins 1 an doit être définie et, pour les niveaux L2 et supérieurs, la politique doit également s'appliquer à tous les sous-domaines.
3.4.2 Vérifier que le champ d'en-tête CORS Access-Control-Allow-Origin a une valeur fixe définie par l'application ou, si la valeur du champ d'en-tête de requête HTTP Origin est utilisée, qu'elle est validée par rapport à une liste d'autorisation d'origines de confiance. Lorsque 'Access-Control-Allow-Origin: *' doit être utilisé, vérifier que la réponse ne contient aucune information sensible.
3.4.3 Vérifier que les réponses HTTP incluent un champ d'en-tête de réponse Content-Security-Policy qui définit des directives pour garantir que le navigateur ne charge et n'exécute que du contenu ou des ressources de confiance, afin de limiter l'exécution de JavaScript malveillant. Au minimum, une politique globale doit être utilisée, incluant les directives object-src 'none' et base-uri 'none', et définissant soit une liste d'autorisation, soit l'utilisation de nonces ou de hachages. Pour une application de niveau L3, une politique par réponse avec des nonces ou des hachages doit être définie.
3.4.4 Vérifier que toutes les réponses HTTP contiennent un champ d'en-tête 'X-Content-Type-Options: nosniff'. Cela indique aux navigateurs de ne pas utiliser la détection de contenu ni la déduction du type MIME pour la réponse donnée, et d'exiger que la valeur du champ d'en-tête Content-Type de la réponse corresponde au type de la ressource de destination. Par exemple, la réponse à une requête pour une feuille de style n'est acceptée que si le Content-Type de la réponse est 'text/css'. Cela permet également l'utilisation de la fonctionnalité Cross-Origin Read Blocking (CORB) par le navigateur.
3.4.5 Vérifier que l'application définit une politique de référent afin d'empêcher la fuite de données techniquement sensibles vers des services tiers via le champ d'en-tête de requête HTTP 'Referer'. Cela peut être fait en utilisant le champ d'en-tête de réponse HTTP Referrer-Policy ou via des attributs d'éléments HTML. Les données sensibles pourraient inclure les données de chemin et de chaîne de requête dans l'URL, et pour les applications internes non publiques, également le nom d'hôte.
3.4.6 Vérifier que l'application web utilise la directive frame-ancestors du champ d'en-tête Content-Security-Policy pour chaque réponse HTTP afin de garantir qu'elle ne peut pas être intégrée par défaut et que l'intégration de ressources spécifiques n'est autorisée que lorsque cela est nécessaire. Notez que le champ d'en-tête X-Frame-Options, bien que pris en charge par les navigateurs, est obsolète et qu'on ne peut pas s'y fier.
3.5.1 Vérifier que, si l'application ne s'appuie pas sur le mécanisme de pré-vérification CORS pour empêcher les requêtes inter-origines non autorisées d'utiliser des fonctionnalités sensibles, ces requêtes sont validées pour s'assurer qu'elles proviennent de l'application elle-même. Cela peut être fait en utilisant et en validant des jetons anti-falsification ou en exigeant des champs d'en-tête HTTP supplémentaires qui ne figurent pas sur la liste des champs d'en-tête de requête sûrs pour CORS. Cela vise à se défendre contre les attaques de falsification de requêtes basées sur le navigateur, communément appelées falsification de requêtes intersites (CSRF).
3.5.2 Vérifier que, si l'application s'appuie sur le mécanisme de pré-vérification CORS pour empêcher l'utilisation inter-origines non autorisée de fonctionnalités sensibles, il n'est pas possible d'appeler la fonctionnalité avec une requête qui ne déclenche pas une requête de pré-vérification CORS. Cela peut nécessiter de vérifier les valeurs des champs d'en-tête de requête 'Origin' et 'Content-Type' ou d'utiliser un champ d'en-tête supplémentaire qui ne figure pas sur la liste des champs d'en-tête sûrs pour CORS.
3.5.3 Vérifier que les requêtes HTTP vers des fonctionnalités sensibles utilisent des méthodes HTTP appropriées telles que POST, PUT, PATCH ou DELETE, et non des méthodes définies par la spécification HTTP comme 'sûres' telles que HEAD, OPTIONS ou GET. Alternativement, une validation stricte des champs d'en-tête de requête Sec-Fetch-* peut être utilisée pour s'assurer que la requête ne provient pas d'un appel inter-origine inapproprié, d'une requête de navigation ou d'un chargement de ressource (comme une image) lorsque cela n'est pas attendu.
3.5.4 Vérifier que les applications distinctes sont hébergées sur des noms d'hôte différents afin de tirer parti des restrictions fournies par la politique de même origine, y compris la manière dont les documents ou scripts chargés par une origine peuvent interagir avec les ressources d'une autre origine et les restrictions basées sur le nom d'hôte pour les cookies.
3.6.1 Vérifier que les ressources côté client, telles que les bibliothèques JavaScript, les feuilles de style CSS ou les polices web, ne sont hébergées en externe (par exemple, sur un réseau de diffusion de contenu ou CDN) que si elles sont statiques et versionnées et si l'intégrité des sous-ressources (Subresource Integrity, SRI) est utilisée pour valider leur intégrité. Si cela n'est pas possible, une décision de sécurité documentée doit justifier ce choix pour chaque ressource.
3.7.1 Vérifier que l'application utilise uniquement des technologies côté client qui sont encore prises en charge et considérées comme sécurisées. Parmi les exemples de technologies qui ne satisfont pas à cette exigence, on trouve les plugins NSAPI, Flash, Shockwave, ActiveX, Silverlight, NACL ou les applets Java côté client.
3.7.3 Vérifier que l'application affiche une notification lorsque l'utilisateur est redirigé vers une URL en dehors du contrôle de l'application, avec une option permettant d'annuler la navigation.
4.1.1 Vérifier que chaque réponse HTTP comportant un corps de message contient un champ d'en-tête Content-Type correspondant au contenu réel de la réponse, y compris le paramètre charset pour spécifier un encodage de caractères sûr (par exemple, UTF-8, ISO-8859-1) conformément aux types de médias IANA, tels que 'text/*', '*/+xml' et '*/xml'.
4.1.4 Vérifier que seules les méthodes HTTP explicitement prises en charge par l'application ou son API (y compris OPTIONS lors des requêtes de pré-vérification) peuvent être utilisées et que les méthodes non utilisées sont bloquées.
4.1.5 Vérifier que des signatures numériques par message sont utilisées pour fournir une garantie supplémentaire en complément des protections de transport pour les requêtes ou transactions hautement sensibles ou traversant plusieurs systèmes.
4.3.1 Vérifier qu'une liste d'autorisation de requêtes, une limitation de profondeur, une limitation du nombre de requêtes ou une analyse du coût des requêtes est utilisée pour prévenir les attaques par déni de service (DoS) contre GraphQL ou la couche d'expression des données, résultant de requêtes imbriquées coûteuses.
5.2.1 Vérifier que l'application n'accepte que des fichiers d'une taille qu'elle peut traiter sans entraîner une perte de performance ni une attaque par déni de service.
5.2.4 Vérifier qu'un quota de taille de fichier et un nombre maximal de fichiers par utilisateur sont appliqués afin de garantir qu'un seul utilisateur ne puisse pas saturer le stockage avec un trop grand nombre de fichiers ou des fichiers excessivement volumineux.
5.3.1 Vérifier que les fichiers téléversés ou générés à partir d'entrées non fiables et stockés dans un dossier public ne sont pas exécutés comme du code côté serveur lorsqu'on y accède directement via une requête HTTP.
5.3.2 Vérifier que lorsque l'application crée des chemins de fichiers pour les opérations sur les fichiers, elle utilise des données générées en interne ou des données de confiance plutôt que des noms de fichiers fournis par l'utilisateur, ou, si des noms de fichiers ou des métadonnées fournis par l'utilisateur doivent être utilisés, qu'une validation et un nettoyage stricts sont appliqués. Ceci vise à protéger contre les attaques de traversée de répertoires, d'inclusion de fichiers locaux ou distants (LFI, RFI) et de falsification de requêtes côté serveur (SSRF).
5.4.1 Vérifier que l'application valide ou ignore les noms de fichiers soumis par l'utilisateur, y compris lorsqu'ils sont transmis dans un paramètre JSON, JSONP ou d'URL, et qu'elle spécifie un nom de fichier dans le champ d'en-tête Content-Disposition de la réponse.
6.1.3 Vérifier que, si l'application comprend plusieurs chemins d'authentification, ceux-ci sont tous documentés ensemble avec les contrôles de sécurité et le niveau de robustesse de l'authentification qui doivent être appliqués de manière cohérente sur l'ensemble de ces chemins.
6.2.1 Vérifier que les mots de passe définis par l'utilisateur comportent au moins 8 caractères, bien qu'un minimum de 15 caractères soit fortement recommandé.
6.2.9 Vérifier que les mots de passe d'au moins 64 caractères sont autorisés.
6.3.1 Vérifier que des contrôles visant à prévenir les attaques telles que le bourrage d'identifiants et les attaques par force brute sur les mots de passe sont mis en œuvre conformément à la documentation de sécurité de l'application.
6.3.2 Vérifier que les comptes utilisateur par défaut (par exemple, 'root', 'admin' ou 'sa') ne sont pas présents dans l'application ou sont désactivés.
6.3.3 Vérifier qu'un mécanisme d'authentification multifacteur ou une combinaison de mécanismes d'authentification à facteur unique doit être utilisé pour accéder à l'application. Pour le niveau L3, l'un des facteurs doit être un mécanisme d'authentification matériel offrant une résistance à la compromission et à l'usurpation d'identité face aux attaques par hameçonnage, tout en vérifiant l'intention de s'authentifier en exigeant une action initiée par l'utilisateur (telle qu'une pression sur un bouton d'une clé matérielle FIDO ou d'un téléphone mobile). L'assouplissement de l'une des considérations de cette exigence nécessite une justification entièrement documentée et un ensemble complet de contrôles d'atténuation.
6.3.6 Vérifier que le courrier électronique n'est pas utilisé comme mécanisme d'authentification à facteur unique ou multifacteur.
6.4.1 Vérifier que les mots de passe initiaux ou les codes d'activation générés par le système sont générés de manière aléatoire et sécurisée, respectent la politique de mots de passe existante et expirent après une courte période ou après leur première utilisation. Ces secrets initiaux ne doivent pas être autorisés à devenir le mot de passe permanent.
6.4.2 Vérifier que les indices de mot de passe ou l'authentification basée sur la connaissance (les « questions secrètes ») ne sont pas utilisés.
6.5.1 Vérifier que les codes de secours, les requêtes ou codes d'authentification hors bande et les mots de passe à usage unique basés sur le temps (TOTP) ne sont utilisables avec succès qu'une seule fois.
6.5.2 Vérifier que, lorsqu'ils sont stockés dans le back-end de l'application, les codes de secours ayant moins de 112 bits d'entropie (19 caractères alphanumériques aléatoires ou 34 chiffres aléatoires) sont hachés avec un algorithme approuvé de hachage pour le stockage des mots de passe intégrant un sel aléatoire de 32 bits. Une fonction de hachage standard peut être utilisée si le secret possède 112 bits d'entropie ou plus.
6.5.3 Vérifier que les codes de secours, les codes d'authentification hors bande et les graines de mots de passe à usage unique basés sur le temps sont générés à l'aide d'un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé (CSPRNG) afin d'éviter les valeurs prévisibles.
7.2.2 Vérifier que l'application utilise des jetons autonomes ou des jetons de référence générés dynamiquement pour la gestion des sessions, c'est-à-dire qu'elle n'utilise pas de secrets et de clés API statiques.
7.2.3 Vérifier que si des jetons de référence sont utilisés pour représenter les sessions utilisateur, ils sont uniques et générés à l'aide d'un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé (CSPRNG) et possèdent au moins 128 bits d'entropie.
7.2.4 Vérifier que l'application génère un nouveau jeton de session lors de l'authentification de l'utilisateur, y compris lors de la réauthentification, et invalide le jeton de session en cours.
7.3.2 Vérifier qu'il existe une durée de vie maximale absolue de la session de sorte que la réauthentification soit imposée conformément à l'analyse des risques et aux décisions de sécurité documentées.
7.4.1 Vérifier que lorsque la fin de session est déclenchée (par exemple lors de la déconnexion ou de l'expiration), l'application interdit toute utilisation ultérieure de la session. Pour les jetons de référence ou les sessions avec état, cela signifie invalider les données de session au niveau du backend de l'application. Les applications utilisant des jetons autonomes devront recourir à une solution telle que la tenue d'une liste de jetons révoqués, l'interdiction des jetons produits avant une date et une heure spécifiques à l'utilisateur, ou la rotation d'une clé de signature propre à chaque utilisateur.
7.4.3 Vérifier que l'application offre la possibilité de mettre fin à toutes les autres sessions actives après une modification ou une suppression réussie de tout facteur d'authentification (y compris le changement de mot de passe via la réinitialisation ou la récupération et, le cas échéant, la mise à jour des paramètres MFA).
7.5.1 Vérifier que l'application exige une réauthentification complète avant d'autoriser la modification d'attributs de compte sensibles susceptibles d'affecter l'authentification, tels que l'adresse e-mail, le numéro de téléphone, la configuration MFA ou toute autre information utilisée pour la récupération de compte.
7.5.2 Vérifier que les utilisateurs sont en mesure de consulter et (après s'être authentifiés à nouveau avec au moins un facteur) de mettre fin à tout ou partie des sessions actuellement actives.
8.1.1 Vérifier que la documentation relative aux autorisations définit des règles pour restreindre l'accès au niveau des fonctions et l'accès spécifique aux données en fonction des permissions des consommateurs et des attributs des ressources.
8.2.1 Vérifier que l'application garantit que l'accès au niveau des fonctions est restreint aux consommateurs disposant de permissions explicites.
8.2.2 Vérifier que l'application garantit que l'accès spécifique aux données est restreint aux consommateurs disposant de permissions explicites sur des éléments de données spécifiques, afin d'atténuer les risques de référence directe non sécurisée à un objet (IDOR) et d'autorisation défaillante au niveau de l'objet (BOLA).
8.3.1 Vérifier que l'application applique les règles d'autorisation au niveau d'une couche de service de confiance et ne s'appuie pas sur des contrôles qu'un consommateur non fiable pourrait manipuler, tels que du JavaScript côté client.
8.4.2 Vérifier que l'accès aux interfaces d'administration intègre plusieurs couches de sécurité, notamment la vérification continue de l'identité du consommateur, l'évaluation de la posture de sécurité de l'appareil et l'analyse contextuelle des risques, en s'assurant que l'emplacement réseau ou les points de terminaison de confiance ne sont pas les seuls facteurs d'autorisation, même s'ils peuvent réduire la probabilité d'un accès non autorisé.
9.1.1 Vérifier que les jetons autonomes sont validés à l'aide de leur signature numérique ou de leur MAC afin de prévenir toute falsification avant d'accepter le contenu du jeton.
10.4.9 Vérifier que les jetons d'actualisation et les jetons d'accès par référence peuvent être révoqués par un utilisateur autorisé via l'interface utilisateur du serveur d'autorisation, afin d'atténuer le risque lié aux clients malveillants ou aux jetons volés.
11.1.2 Vérifier qu'un inventaire cryptographique est réalisé, maintenu, régulièrement mis à jour et inclut toutes les clés cryptographiques, tous les algorithmes et tous les certificats utilisés par l'application. Il doit également documenter les endroits où les clés peuvent et ne peuvent pas être utilisées dans le système, ainsi que les types de données qui peuvent et ne peuvent pas être protégés à l'aide des clés.
11.2.1 Vérifier que des implémentations validées par l'industrie (y compris les bibliothèques et les implémentations à accélération matérielle) sont utilisées pour les opérations cryptographiques.
11.2.2 Vérifier que l'application est conçue avec une agilité cryptographique telle que les algorithmes de génération de nombres aléatoires, de chiffrement authentifié, de MAC ou de hachage, les longueurs de clé, les nombres de tours, les algorithmes de chiffrement et les modes peuvent être reconfigurés, mis à niveau ou remplacés à tout moment, afin de se protéger contre les failles cryptographiques. De même, il doit également être possible de remplacer les clés et les mots de passe et de rechiffrer les données. Cela permettra des mises à niveau transparentes vers la cryptographie post-quantique (PQC), une fois que des implémentations à haut niveau d'assurance des schémas ou normes PQC approuvés seront largement disponibles.
11.2.4 Vérifier que toutes les opérations cryptographiques s'exécutent en temps constant, sans opérations à évaluation partielle dans les comparaisons, les calculs ou les instructions de retour, afin d'éviter les fuites d'informations.
11.2.5 Vérifier que tous les modules cryptographiques échouent en mode sécurisé et que les erreurs sont gérées de façon à ne pas favoriser l'apparition de vulnérabilités, telles que les attaques par oracle de remplissage (Padding Oracle).
11.3.1 Vérifier que les modes de chiffrement par blocs non sécurisés (par ex. ECB) et les schémas de remplissage faibles (par ex. PKCS#1 v1.5) ne sont pas utilisés.
11.3.3 Vérifier que les données chiffrées sont protégées contre toute modification non autorisée, de préférence en utilisant une méthode de chiffrement authentifié approuvée ou en combinant une méthode de chiffrement approuvée avec un algorithme MAC approuvé.
11.3.4 Vérifier que les nonces, les vecteurs d'initialisation et les autres nombres à usage unique ne sont pas utilisés pour plus d'une paire clé de chiffrement/élément de données. La méthode de génération doit être appropriée à l'algorithme utilisé.
11.4.2 Vérifier que les mots de passe sont stockés à l'aide d'une fonction de dérivation de clé approuvée et à forte intensité de calcul (également connue sous le nom de 'fonction de hachage de mot de passe'), avec des paramètres configurés conformément aux recommandations en vigueur. Les paramètres doivent équilibrer sécurité et performance afin de rendre les attaques par force brute suffisamment difficiles pour le niveau de sécurité requis.
11.5.1 Vérifier que tous les nombres et chaînes aléatoires qui ne doivent pas pouvoir être devinés sont générés à l'aide d'un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé (CSPRNG) et possèdent au moins 128 bits d'entropie. Notez que les UUID ne satisfont pas à cette condition.
11.5.2 Vérifier que le mécanisme de génération de nombres aléatoires utilisé est conçu pour fonctionner de manière sécurisée, même en cas de forte sollicitation.
12.1.1 Vérifier que seules les dernières versions recommandées du protocole TLS sont activées, telles que TLS 1.2 et TLS 1.3. La dernière version du protocole TLS doit être l'option privilégiée.
12.2.1 Vérifier que TLS est utilisé pour toute connectivité entre un client et les services HTTP exposés à l'extérieur, et qu'il n'y a pas de repli vers des communications non sécurisées ou non chiffrées.
12.3.1 Vérifier qu'un protocole chiffré tel que TLS est utilisé pour toutes les connexions entrantes et sortantes de l'application, y compris les systèmes de surveillance, les outils de gestion, l'accès à distance et SSH, les intergiciels, les bases de données, les mainframes, les systèmes partenaires ou les API externes. Le serveur ne doit pas basculer vers des protocoles non sécurisés ou non chiffrés.
12.3.4 Vérifier que les connexions TLS entre les services internes utilisent des certificats de confiance. Lorsque des certificats générés en interne ou auto-signés sont utilisés, le service consommateur doit être configuré pour faire confiance uniquement à des autorités de certification internes spécifiques et à des certificats auto-signés spécifiques.
12.3.5 Vérifier que les services communiquant en interne au sein d'un système (communications intra-services) utilisent une authentification forte pour garantir que chaque point de terminaison est vérifié. Des méthodes d'authentification forte, telles que l'authentification client TLS, doivent être employées pour garantir l'identité, en utilisant une infrastructure à clé publique et des mécanismes résistants aux attaques par rejeu. Pour les architectures de microservices, envisagez l'utilisation d'un maillage de services (service mesh) pour simplifier la gestion des certificats et renforcer la sécurité.
13.2.1 Vérifier que les communications entre les composants applicatifs back-end qui ne prennent pas en charge le mécanisme standard de session utilisateur de l'application, y compris les API, les intergiciels et les couches de données, sont authentifiées. L'authentification doit utiliser des comptes de service individuels, des jetons à courte durée de vie ou une authentification par certificat, et non des identifiants statiques tels que des mots de passe, des clés API ou des comptes partagés avec accès privilégié.
13.2.2 Vérifier que les communications entre les composants applicatifs back-end, y compris les services locaux ou du système d'exploitation, les API, les intergiciels et les couches de données, sont effectuées avec des comptes disposant des privilèges minimaux nécessaires.
13.2.5 Vérifier que le serveur web ou d'applications est configuré avec une liste d'autorisation des ressources ou systèmes vers lesquels le serveur peut envoyer des requêtes ou à partir desquels il peut charger des données ou des fichiers.
13.3.1 Vérifier qu'une solution de gestion des secrets, telle qu'un coffre-fort de clés, est utilisée pour créer, stocker, contrôler l'accès aux secrets du back-end et les détruire de manière sécurisée. Ceux-ci peuvent inclure des mots de passe, du matériel cryptographique, des intégrations avec des bases de données et des systèmes tiers, des clés et des valeurs initiales pour les jetons temporels, d'autres secrets internes et des clés API. Les secrets ne doivent pas être inclus dans le code source de l'application ni dans les artefacts de build. Pour une application L3, cela doit impliquer une solution adossée à un matériel, telle qu'un HSM.
13.3.3 Vérifier que toutes les opérations cryptographiques sont effectuées à l'aide d'un module de sécurité isolé (tel qu'un coffre-fort ou un module de sécurité matériel) pour gérer et protéger de manière sécurisée le matériel cryptographique contre toute exposition en dehors du module de sécurité.
13.4.2 Vérifier que les modes de débogage sont désactivés pour tous les composants dans les environnements de production afin d'empêcher l'exposition des fonctionnalités de débogage et les fuites d'informations.
13.4.3 Vérifier que les serveurs web n'exposent pas de listes de répertoires aux clients, sauf si cela est explicitement prévu.
13.4.5 Vérifier que la documentation (telle que celle des API internes) et les points de terminaison de supervision ne sont pas exposés, sauf si cela est explicitement prévu.
13.4.6 Vérifier que l'application n'expose pas d'informations détaillées sur les versions des composants backend.
13.4.7 Vérifier que la couche web est configurée pour ne servir que des fichiers avec des extensions de fichier spécifiques afin d'empêcher les fuites involontaires d'informations, de configuration et de code source.
14.1.1 Vérifier que toutes les données sensibles créées et traitées par l'application ont été identifiées et classifiées selon des niveaux de protection. Cela inclut les données qui sont uniquement encodées et donc facilement décodables, telles que les chaînes Base64 ou le contenu en clair à l'intérieur d'un JWT. Les niveaux de protection doivent tenir compte de toutes les réglementations et normes en matière de protection des données et de respect de la vie privée auxquelles l'application est tenue de se conformer.
14.1.2 Vérifier que tous les niveaux de protection des données sensibles disposent d'un ensemble documenté d'exigences de protection. Cela doit inclure (sans s'y limiter) les exigences relatives au chiffrement général, à la vérification de l'intégrité, à la conservation, à la manière dont les données doivent être journalisées, aux contrôles d'accès aux données sensibles présentes dans les journaux, au chiffrement au niveau de la base de données, à la confidentialité et aux technologies d'amélioration de la protection de la vie privée à utiliser, ainsi qu'aux autres exigences de confidentialité.
14.2.1 Vérifier que les données sensibles sont envoyées au serveur uniquement dans le corps du message HTTP ou dans les champs d'en-tête, et que l'URL et la chaîne de requête ne contiennent pas d'informations sensibles, telles qu'une clé API ou un jeton de session.
14.2.2 Vérifier que l'application empêche la mise en cache des données sensibles dans les composants serveur, tels que les répartiteurs de charge et les caches applicatifs, ou s'assure que les données sont purgées de manière sécurisée après utilisation.
14.3.3 Vérifier que les données stockées dans le stockage du navigateur (telles que localStorage, sessionStorage, IndexedDB ou les cookies) ne contiennent pas de données sensibles, à l'exception des jetons de session.
15.1.2 Vérifier qu'un catalogue d'inventaire, tel qu'une nomenclature logicielle (SBOM), est tenu à jour pour toutes les bibliothèques tierces utilisées, y compris en vérifiant que les composants proviennent de dépôts prédéfinis, fiables et continuellement maintenus.
15.2.4 Vérifier que les composants tiers et toutes leurs dépendances transitives proviennent du dépôt attendu, qu'il soit interne ou externe, et qu'il n'existe aucun risque d'attaque par confusion de dépendances.
15.3.3 Vérifier que l'application dispose de contre-mesures pour se protéger contre les attaques par affectation de masse en limitant les champs autorisés par contrôleur et par action, par exemple, qu'il n'est pas possible d'insérer ou de mettre à jour la valeur d'un champ lorsque celui-ci n'était pas destiné à faire partie de cette action.
15.3.7 Vérifier que l'application dispose de défenses contre les attaques par pollution de paramètres HTTP, en particulier si le framework applicatif ne fait pas de distinction quant à la source des paramètres de requête (chaîne de requête, paramètres du corps, cookies ou champs d'en-tête).
15.4.1 Vérifier que les objets partagés dans le code multithread (tels que les caches, les fichiers ou les objets en mémoire accessibles par plusieurs threads) font l'objet d'un accès sécurisé grâce à l'utilisation de types thread-safe et de mécanismes de synchronisation tels que les verrous ou les sémaphores, afin d'éviter les conditions de concurrence et la corruption des données.
15.4.2 Vérifier que les vérifications de l'état d'une ressource, telles que son existence ou ses permissions, et les actions qui en dépendent sont effectuées en une seule opération atomique afin d'empêcher les conditions de concurrence de type TOCTOU (time-of-check to time-of-use). Par exemple, vérifier si un fichier existe avant de l'ouvrir, ou vérifier l'accès d'un utilisateur avant de l'accorder.
16.2.1 Vérifier que chaque entrée de journal inclut les métadonnées nécessaires (telles que quand, où, qui, quoi) permettant une enquête détaillée sur la chronologie lorsqu'un événement se produit.
16.2.5 Vérifier que, lors de la journalisation de données sensibles, l'application applique des règles de journalisation en fonction du niveau de protection des données. Par exemple, il peut être interdit de journaliser certaines données, telles que les identifiants ou les informations de paiement. D'autres données, telles que les jetons de session, ne peuvent être journalisées que si elles sont hachées ou masquées, totalement ou partiellement.
16.3.3 Vérifier que l'application journalise les événements de sécurité définis dans la documentation et journalise également les tentatives de contournement des contrôles de sécurité, tels que la validation des entrées, la logique métier et l'anti-automatisation.
16.4.1 Vérifier que tous les composants de journalisation encodent correctement les données afin d'empêcher l'injection dans les journaux.
16.4.2 Vérifier que les journaux sont protégés contre tout accès non autorisé et ne peuvent pas être altérés.
16.5.1 Vérifier qu'un message générique est renvoyé au consommateur lorsqu'une erreur inattendue ou liée à la sécurité se produit, afin de garantir qu'aucune donnée interne sensible du système, telle que les traces de pile, les requêtes, les clés secrètes et les jetons, n'est exposée.
16.5.3 Vérifier que l'application échoue de manière contrôlée et sécurisée, y compris lorsqu'une exception se produit, en empêchant les conditions de type « fail-open » telles que le traitement d'une transaction malgré des erreurs résultant de la logique de validation.
16.5.4 Vérifier qu'un gestionnaire d'erreurs de 'dernier recours' est défini pour intercepter toutes les exceptions non gérées. Cela permet à la fois d'éviter la perte de détails d'erreur qui doivent être consignés dans les fichiers journaux et de s'assurer qu'une erreur ne provoque pas l'arrêt de l'ensemble du processus applicatif, entraînant une perte de disponibilité.