Rapport de vérification de la sécurité des applications OWASP

ID	Nom
1.2.1	Vérifiez l'utilisation de comptes système d'exploitation uniques ou spéciaux à faibles privilèges pour tous les composants, services et serveurs d'application.
1.2.2	Vérifiez que les communications entre les composants de l'application, y compris les API, les intergiciels et les couches de données, sont authentifiées. Les composants devraient avoir les privilèges nécessaires les plus restreints possibles.
1.2.3	Vérifiez que l'application utilise un seul mécanisme d'authentification approuvé qui est connu pour être sécurisé, peut être étendu pour inclure une authentification forte, et dispose d'une surveillance et d'un enregistrement suffisants pour détecter les abus de compte ou les violations.
1.2.4	Vérifiez que tous les chemins d'authentification et les API de gestion d'identité mettent en œuvre une force de contrôle de sécurité d'authentification cohérente, de sorte qu'il n'y ait pas d'alternatives plus faibles en fonction du risque de l'application.
1.4.4	Vérifiez que l'application utilise un mécanisme de contrôle d'accès unique et bien vérifié pour accéder aux données et ressources protégées. Toutes les demandes doivent passer par ce seul mécanisme pour éviter le copier-coller ou les chemins alternatifs non sécurisés.
1.4.5	Vérifiez que le contrôle d'accès basé sur les attributs ou les fonctionnalités est utilisé, où le code vérifie l'autorisation de l'utilisateur pour une fonctionnalité/élément de données plutôt que simplement leur rôle. Les autorisations devraient toujours être attribuées en utilisant des rôles.
1.5.2	Vérifiez que la sérialisation n'est pas utilisée lors de la communication avec des clients non fiables. Si cela n'est pas possible, assurez-vous que des contrôles d'intégrité adéquats (et éventuellement un chiffrement si des données sensibles sont envoyées) sont appliqués pour prévenir les attaques de désérialisation, y compris l'injection d'objets.
1.5.3	Vérifiez que la validation des entrées est appliquée sur une couche de service de confiance.
1.5.4	Vérifiez que le codage de sortie se produit près de ou par l'interprète pour lequel il est destiné.
1.6.2	Vérifiez que les consommateurs de services cryptographiques protègent le matériel clé et autres secrets en utilisant des coffres-forts de clés ou des alternatives basées sur l'API.
1.6.3	Vérifiez que toutes les clés et les mots de passe sont remplaçables et font partie d'un processus bien défini pour re-chiffrer les données sensibles.
1.6.4	Vérifiez que l'architecture traite les secrets côté client - tels que les clés symétriques, les mots de passe ou les jetons API - comme non sécurisés et ne les utilise jamais pour protéger ou accéder à des données sensibles.
1.9.1	Vérifiez que l'application chiffre les communications entre les composants, en particulier lorsque ces composants se trouvent dans différents conteneurs, systèmes, sites ou fournisseurs de cloud.
1.9.2	Vérifiez que les composants de l'application vérifient l'authenticité de chaque côté d'un lien de communication pour prévenir les attaques de type intermédiaire. Par exemple, les composants de l'application devraient valider les certificats TLS et les chaînes.
1.11.2	Vérifiez que tous les flux de logique commerciale à haute valeur, y compris l'authentification, la gestion des sessions et le contrôle d'accès, ne partagent pas d'état non synchronisé.
1.11.3	Vérifiez que tous les flux de logique d'entreprise à haute valeur, y compris l'authentification, la gestion des sessions et le contrôle d'accès, sont à l'épreuve des threads et résistent aux conditions de course entre le moment de la vérification et le moment de l'utilisation.
1.14.6	Vérifiez que l'application n'utilise pas de technologies côté client non prises en charge, non sécurisées ou obsolètes telles que les plugins NSAPI, Flash, Shockwave, ActiveX, Silverlight, NACL ou les applets Java côté client.
2.1.1	Vérifiez que les mots de passe définis par l'utilisateur ont au moins 12 caractères de longueur (après que plusieurs espaces soient combinés).
2.1.2	Vérifiez que les mots de passe d'au moins 64 caractères sont autorisés, et que les mots de passe de plus de 128 caractères sont refusés.
2.2.1	Vérifiez que les contrôles anti-automatisation sont efficaces pour atténuer les tests de violation de crédentials, les attaques par force brute et les attaques de verrouillage de compte. Ces contrôles incluent le blocage des mots de passe les plus couramment violés, les verrouillages temporaires, la limitation du taux, le CAPTCHA, des délais de plus en plus longs entre les tentatives, les restrictions d'adresse IP, ou des restrictions basées sur le risque telles que l'emplacement, la première connexion sur un appareil, les tentatives récentes de déverrouillage du compte, ou similaires. Vérifiez qu'il n'est pas possible d'avoir plus de 100 tentatives échouées par heure sur un seul compte.
2.2.2	Vérifiez que l'utilisation d'authentificateurs faibles (tels que les SMS et les emails) est limitée à la vérification secondaire et à l'approbation des transactions, et non comme un remplacement pour des méthodes d'authentification plus sécurisées. Vérifiez que des méthodes plus fortes sont proposées avant les méthodes faibles, que les utilisateurs sont conscients des risques, ou que des mesures appropriées sont en place pour limiter les risques de compromission de compte.
2.2.4	Vérifiez la résistance à l'usurpation d'identité contre le hameçonnage, comme l'utilisation de l'authentification à plusieurs facteurs, des dispositifs cryptographiques avec intention (comme des clés connectées avec une pression pour authentifier), ou à des niveaux AAL plus élevés, des certificats côté client.
2.2.5	Vérifiez que là où un fournisseur de services d'identification (CSP) et l'application vérifiant l'authentification sont séparés, un TLS mutuellement authentifié est en place entre les deux points d'extrémité.
2.2.6	Vérifiez la résistance à la relecture grâce à l'utilisation obligatoire de dispositifs de mots de passe à usage unique (OTP), d'authentificateurs cryptographiques ou de codes de recherche.
2.3.1	Vérifiez que les mots de passe initiaux ou les codes d'activation générés par le système DOIVENT être générés de manière aléatoire et sécurisée, DOIVENT comporter au moins 6 caractères et PEUVENT contenir des lettres et des chiffres, et expirer après une courte période de temps. Ces secrets initiaux ne doivent pas être autorisés à devenir le mot de passe à long terme.
2.4.1	Vérifiez que les mots de passe sont stockés sous une forme résistante aux attaques hors ligne. Les mots de passe DOIVENT être salés et hachés en utilisant une fonction de dérivation de clé unidirectionnelle ou de hachage de mot de passe approuvée. Les fonctions de dérivation de clé et de hachage de mot de passe prennent un mot de passe, un sel et un facteur de coût en entrée lors de la génération d'un hachage de mot de passe.
2.4.2	Vérifiez que le sel a une longueur d'au moins 32 bits et qu'il est choisi arbitrairement pour minimiser les collisions de valeurs de sel parmi les hachages stockés. Pour chaque identifiant, une valeur de sel unique et le hachage résultant DOIVENT être stockés.
2.4.3	Vérifiez que si PBKDF2 est utilisé, le nombre d'itérations DEVRAIT être aussi grand que les performances du serveur de vérification le permettent, généralement au moins 100 000 itérations.
2.4.4	Vérifiez que si bcrypt est utilisé, le facteur de travail DEVRAIT être aussi grand que les performances du serveur de vérification le permettent, avec un minimum de 10.
2.4.5	Vérifiez qu'une itération supplémentaire d'une fonction de dérivation de clé est effectuée, en utilisant une valeur de sel qui est secrète et connue uniquement du vérificateur. Générez la valeur de sel en utilisant un générateur de bits aléatoires approuvé [SP 800-90Ar1] et fournissez au moins la force de sécurité minimale spécifiée dans la dernière révision de SP 800-131A. La valeur secrète du sel DOIT être stockée séparément des mots de passe hachés (par exemple, dans un dispositif spécialisé comme un module de sécurité matériel).
2.5.1	Vérifiez qu'un secret d'activation ou de récupération initial généré par le système n'est pas envoyé en clair à l'utilisateur.
2.5.2	Vérifiez que les indices de mot de passe ou l'authentification basée sur la connaissance (soi-disant questions secrètes) ne sont pas présents.
2.5.3	Vérifiez que la récupération des informations d'identification du mot de passe ne révèle en aucun cas le mot de passe actuel.
2.5.4	Vérifiez que les comptes partagés ou par défaut ne sont pas présents (par exemple, root, admin, ou sa).
2.6.1	Vérifiez que les secrets de recherche ne peuvent être utilisés qu'une seule fois.
2.6.2	Vérifiez que les secrets de recherche ont une aléatoire suffisante (112 bits d'entropie), ou si moins de 112 bits d'entropie, salés avec un sel unique et aléatoire de 32 bits et hachés avec un hachage unidirectionnel approuvé.
2.6.3	Vérifiez que les secrets de recherche résistent aux attaques hors ligne, comme les valeurs prévisibles.
2.10.1	Vérifiez que les secrets intra-service ne dépendent pas de justificatifs d'identité immuables tels que les mots de passe, les clés API ou les comptes partagés avec un accès privilégié.
2.10.2	Vérifiez que si des mots de passe sont requis pour l'authentification du service, le compte de service utilisé n'est pas une authentification par défaut. (par exemple, root/root ou admin/admin sont par défaut dans certains services lors de l'installation).
2.10.3	Vérifiez que les mots de passe sont stockés avec une protection suffisante pour prévenir les attaques de récupération hors ligne, y compris l'accès au système local.
2.10.4	Vérifiez que les mots de passe, les intégrations avec les bases de données et les systèmes tiers, les graines et les secrets internes, et les clés API sont gérés de manière sécurisée et ne sont pas inclus dans le code source ou stockés dans les dépôts de code source. Un tel stockage DEVRAIT résister aux attaques hors ligne. L'utilisation d'un magasin de clés logiciel sécurisé (L1), d'un TPM matériel, ou d'un HSM (L3) est recommandée pour le stockage des mots de passe.
3.1.1	Vérifiez que l'application ne révèle jamais les jetons de session dans les paramètres d'URL.
3.2.1	Vérifiez que l'application génère un nouveau jeton de session lors de l'authentification de l'utilisateur.
3.2.2	Vérifiez que les jetons de session possèdent au moins 64 bits d'entropie.
3.2.3	Vérifiez que l'application ne stocke les jetons de session dans le navigateur qu'en utilisant des méthodes sécurisées telles que des cookies correctement sécurisés (voir section 3.4) ou le stockage de session HTML 5.
3.2.4	Vérifiez que les jetons de session sont générés en utilisant des algorithmes cryptographiques approuvés.
3.3.1	Vérifiez que la déconnexion et l'expiration invalident le jeton de session, de sorte que le bouton de retour ou une partie dépendante en aval ne reprenne pas une session authentifiée, y compris entre les parties dépendantes.
3.3.2	Si les authentificateurs permettent aux utilisateurs de rester connectés, vérifiez que la ré-authentification se produit périodiquement, à la fois lorsqu'elle est activement utilisée ou après une période d'inactivité.
3.3.3	Vérifiez que l'application offre l'option de terminer toutes les autres sessions actives après un changement de mot de passe réussi (y compris le changement via la réinitialisation/récupération du mot de passe), et que cela est efficace à travers l'application, la connexion fédérée (si présente), et toutes les parties qui s'y fient.
3.3.4	Vérifiez que les utilisateurs sont capables de voir et (après avoir ressaisi leurs identifiants de connexion) de se déconnecter de toutes les sessions et tous les appareils actuellement actifs.
3.4.1	Vérifiez que les jetons de session basés sur les cookies ont l'attribut 'Secure' défini.
3.4.2	Vérifiez que les jetons de session basés sur les cookies ont l'attribut 'HttpOnly' défini
3.4.3	Vérifiez que les jetons de session basés sur les cookies utilisent l'attribut 'SameSite' pour limiter l'exposition aux attaques de falsification de requêtes inter-sites.
3.4.4	Vérifiez que les jetons de session basés sur les cookies utilisent le préfixe '__Host-' afin que les cookies ne soient envoyés qu'à l'hôte qui a initialement défini le cookie.
3.4.5	Vérifiez que si l'application est publiée sous un nom de domaine avec d'autres applications qui définissent ou utilisent des cookies de session susceptibles de divulguer les cookies de session, définissez l'attribut de chemin dans les jetons de session basés sur les cookies en utilisant le chemin le plus précis possible.
3.5.1	Vérifiez que l'application permet aux utilisateurs de révoquer les jetons OAuth qui forment des relations de confiance avec les applications liées.
3.5.2	Vérifiez que l'application utilise des jetons de session plutôt que des secrets et des clés API statiques, sauf avec les implémentations héritées.
3.5.3	Vérifiez que les jetons de session sans état utilisent des signatures numériques, le chiffrement et d'autres contre-mesures pour se protéger contre les attaques de falsification, d'enveloppement, de relecture, de chiffrement nul et de substitution de clé.
3.7.1	Vérifiez que l'application assure une session de connexion complète et valide ou nécessite une nouvelle authentification ou une vérification secondaire avant d'autoriser toute transaction sensible ou modification de compte.
4.1.1	Vérifiez que l'application applique les règles de contrôle d'accès sur une couche de service de confiance, surtout si le contrôle d'accès côté client est présent et pourrait être contourné.
4.1.2	Vérifiez que tous les attributs des utilisateurs et des données ainsi que les informations de politique utilisées par les contrôles d'accès ne peuvent pas être manipulés par les utilisateurs finaux à moins d'y être spécifiquement autorisés.
4.1.3	Vérifiez que le principe du moindre privilège existe - les utilisateurs ne devraient être en mesure d'accéder qu'aux fonctions, fichiers de données, URL, contrôleurs, services et autres ressources, pour lesquels ils possèdent une autorisation spécifique. Cela implique une protection contre le spoofing et l'élévation de privilège.
4.1.5	Vérifiez que les contrôles d'accès échouent de manière sécurisée, y compris lorsqu'une exception se produit.
4.2.1	Vérifiez que les données sensibles et les API sont protégées contre les attaques de référence d'objet direct non sécurisé (IDOR) visant la création, la lecture, la mise à jour et la suppression d'enregistrements, tels que la création ou la mise à jour de l'enregistrement de quelqu'un d'autre, la visualisation des enregistrements de tout le monde, ou la suppression de tous les enregistrements.
4.2.2	Vérifiez que l'application ou le cadre d'application applique un mécanisme anti-CSRF fort pour protéger les fonctionnalités authentifiées, et qu'un anti-automatisation ou anti-CSRF efficace protège les fonctionnalités non authentifiées.
4.3.2	Vérifiez que la navigation dans les répertoires est désactivée à moins qu'elle ne soit délibérément souhaitée. De plus, les applications ne devraient pas permettre la découverte ou la divulgation des métadonnées de fichiers ou de répertoires, tels que Thumbs.db, .DS_Store, les dossiers .git ou .svn.
5.1.1	Vérifiez que l'application a des défenses contre les attaques de pollution de paramètres HTTP, en particulier si le cadre de l'application ne fait aucune distinction quant à la source des paramètres de demande (GET, POST, cookies, en-têtes ou variables d'environnement).
5.1.2	Vérifiez que les cadres protègent contre les attaques de masse par affectation de paramètres, ou que l'application a des contre-mesures pour se protéger contre l'affectation de paramètres non sécurisée, comme marquer les champs privés ou similaires.
5.1.3	Vérifiez que toutes les entrées (champs de formulaire HTML, requêtes REST, paramètres URL, en-têtes HTTP, cookies, fichiers batch, flux RSS, etc.) sont validées en utilisant une validation positive (listes d'autorisation).
5.1.4	Vérifiez que les données structurées sont fortement typées et validées par rapport à un schéma défini, y compris les caractères autorisés, la longueur et le motif (par exemple, les numéros de carte de crédit, les adresses e-mail, les numéros de téléphone, ou la validation que deux champs liés sont raisonnables, comme vérifier que le quartier et le code postal correspondent).
5.1.5	Vérifiez que les redirections et les renvois d'URL n'autorisent que des destinations qui figurent sur une liste d'autorisation, ou affichez un avertissement lors de la redirection vers un contenu potentiellement non fiable.
5.2.1	Vérifiez que toutes les entrées HTML non fiables provenant d'éditeurs WYSIWYG ou similaires sont correctement assainies avec une bibliothèque d'assainissement HTML ou une fonctionnalité de framework.
5.2.2	Vérifiez que les données non structurées sont assainies pour appliquer des mesures de sécurité telles que les caractères autorisés et la longueur.
5.2.3	Vérifiez 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.
5.2.4	Vérifiez que l'application évite l'utilisation de eval() ou d'autres fonctionnalités d'exécution de code dynamique. Là où il n'y a pas d'alternative, toute entrée utilisateur incluse doit être assainie ou mise en bac à sable avant d'être exécutée.
5.2.6	Vérifiez que l'application se protège contre les attaques SSRF, en validant ou en assainissant les données non fiables ou les métadonnées de fichiers HTTP, telles que les noms de fichiers et les champs d'entrée d'URL, et utilise des listes d'autorisation de protocoles, de domaines, de chemins et de ports.
5.2.7	Vérifiez que l'application assainit, désactive ou met en bac à sable le contenu scriptable fourni par l'utilisateur en Scalable Vector Graphics (SVG), en particulier en ce qui concerne les XSS résultant de scripts en ligne, et foreignObject.
5.2.8	Vérifiez que l'application assainit, désactive ou met en bac à sable le contenu fourni par l'utilisateur pouvant être scripté ou basé sur un langage de modèle d'expression, tel que Markdown, CSS ou feuilles de style XSL, BBCode, ou similaire.
5.3.1	Vérifiez que le codage de sortie est pertinent pour l'interprète et le contexte requis. Par exemple, utilisez des encodeurs spécifiquement pour les valeurs HTML, les attributs HTML, JavaScript, les paramètres URL, les en-têtes HTTP, SMTP, et autres selon le contexte requis, en particulier à partir d'entrées non fiables (par exemple, des noms avec Unicode ou des apostrophes, comme ねこou O'Hara).
5.3.2	Vérifiez que le codage de sortie préserve l'ensemble de caractères et les paramètres régionaux choisis par l'utilisateur, de sorte que tout point de caractère Unicode est valide et géré en toute sécurité.
5.3.3	Vérifiez que l'échappement de sortie conscient du contexte, de préférence automatisé - ou au pire, manuel - protège contre les XSS reflétés, stockés et basés sur le DOM.
5.3.4	Vérifiez que la sélection de données ou les requêtes de base de données (par exemple, SQL, HQL, ORM, NoSQL) utilisent des requêtes paramétrées, des ORM, des cadres d'entités, ou sont autrement protégées contre les attaques d'injection de base de données.
5.3.5	Vérifiez que lorsque des mécanismes paramétrés ou plus sûrs ne sont pas présents, un codage de sortie spécifique au contexte est utilisé pour se protéger contre les attaques par injection, comme l'utilisation de l'échappement SQL pour se protéger contre l'injection SQL.
5.3.6	Vérifiez que l'application protège contre les attaques par injection JSON, les attaques par évaluation JSON et l'évaluation d'expressions JavaScript.
5.3.7	Vérifiez que l'application protège contre les vulnérabilités d'injection LDAP, ou que des contrôles de sécurité spécifiques pour prévenir l'injection LDAP ont été mis en place.
5.3.8	Vérifiez que l'application se protège contre l'injection de commandes OS et que les appels au système d'exploitation utilisent des requêtes OS paramétrées ou utilisent un codage de sortie de ligne de commande contextuel.
5.3.9	Vérifiez que l'application protège contre les attaques d'inclusion de fichiers locaux (LFI) ou d'inclusion de fichiers distants (RFI).
5.3.10	Vérifiez que l'application se protège contre les attaques par injection XPath ou injection XML.
5.4.1	Vérifiez que l'application utilise une chaîne de mémoire sécurisée, une copie de mémoire plus sûre et une arithmétique de pointeur pour détecter ou prévenir les débordements de pile, de tampon ou de tas.
5.4.2	Vérifiez que les chaînes de format ne prennent pas d'entrée potentiellement hostile et sont constantes.
5.4.3	Vérifiez que les techniques de validation de signe, de plage et d'entrée sont utilisées pour prévenir les débordements d'entiers.
5.5.1	Vérifiez que les objets sérialisés utilisent des contrôles d'intégrité ou sont chiffrés pour prévenir la création d'objets hostiles ou la falsification de données.
5.5.2	Vérifiez que l'application restreint correctement les analyseurs XML à n'utiliser que la configuration la plus restrictive possible et à garantir que les fonctionnalités dangereuses telles que la résolution d'entités externes sont désactivées pour prévenir les attaques XML eXternal Entity (XXE).
5.5.3	Vérifiez que la désérialisation de données non fiables est évitée ou protégée à la fois dans le code personnalisé et dans les bibliothèques tierces (telles que les analyseurs JSON, XML et YAML).
5.5.4	Vérifiez que lors de l'analyse JSON dans les navigateurs ou les backends basés sur JavaScript, JSON.parse est utilisé pour analyser le document JSON. N'utilisez pas eval() pour analyser JSON.
6.1.1	Vérifiez que les données privées réglementées sont stockées de manière cryptée lorsqu'elles sont au repos, comme les informations personnelles identifiables (PII), les informations personnelles sensibles ou les données jugées susceptibles d'être soumises au RGPD de l'UE.
6.1.2	Vérifiez que les données de santé réglementées sont stockées de manière cryptée lorsqu'elles sont au repos, comme les dossiers médicaux, les détails des dispositifs médicaux ou les dossiers de recherche désanonymisés.
6.1.3	Vérifiez que les données financières réglementées sont stockées de manière cryptée lorsqu'elles sont au repos, telles que les comptes financiers, les défauts ou l'historique de crédit, les dossiers fiscaux, l'historique de paiement, les bénéficiaires ou les dossiers de marché ou de recherche désanonymisés.
6.2.1	Vérifiez que tous les modules cryptographiques échouent de manière sécurisée, et que les erreurs sont gérées de manière à ne pas permettre les attaques de Padding Oracle.
6.2.2.	Vérifiez que des algorithmes, modes et bibliothèques cryptographiques éprouvés par l'industrie ou approuvés par le gouvernement sont utilisés, au lieu d'une cryptographie codée sur mesure.
6.2.3	Vérifiez que le vecteur d'initialisation du chiffrement, la configuration du chiffre et les modes de bloc sont configurés de manière sécurisée en utilisant les derniers conseils.
6.2.4	Vérifiez que les nombres aléatoires, les algorithmes de chiffrement ou de hachage, les longueurs de clés, les tours, les chiffrements ou les modes, peuvent être reconfigurés, améliorés ou échangés à tout moment, pour se protéger contre les ruptures cryptographiques.
6.2.5	Vérifiez que les modes de blocs connus comme non sécurisés (c'est-à-dire ECB, etc.), les modes de remplissage (c'est-à-dire PKCS#1 v1.5, etc.), les chiffrements avec de petites tailles de blocs (c'est-à-dire Triple-DES, Blowfish, etc.) et les algorithmes de hachage faibles (c'est-à-dire MD5, SHA1, etc.) ne sont pas utilisés sauf si nécessaire pour la compatibilité descendante.
6.2.6	Vérifiez que les nonces, les vecteurs d'initialisation et les autres nombres à usage unique ne doivent pas être utilisés plus d'une fois avec une clé de chiffrement donnée. La méthode de génération doit être appropriée pour l'algorithme utilisé.
6.2.7	Vérifiez que les données cryptées sont authentifiées par des signatures, des modes de chiffrement authentifiés ou HMAC pour garantir que le texte chiffré n'est pas modifié par une partie non autorisée.
6.2.8	Vérifiez que toutes les opérations cryptographiques sont constantes, sans opérations de 'court-circuit' dans les comparaisons, les calculs ou les retours, pour éviter de divulguer des informations.
6.3.1	Vérifiez que tous les nombres aléatoires, les noms de fichiers aléatoires, les GUID aléatoires et les chaînes aléatoires sont générés à l'aide du générateur de nombres aléatoires sécurisé cryptographiquement approuvé du module cryptographique lorsque ces valeurs aléatoires sont censées ne pas être devinables par un attaquant.
6.3.2	Vérifiez que les GUID aléatoires sont créés en utilisant l'algorithme GUID v4 et un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé (CSPRNG). Les GUID créés à l'aide d'autres générateurs de nombres pseudo-aléatoires peuvent être prévisibles.
6.3.3	Vérifiez que des nombres aléatoires sont créés avec une entropie appropriée même lorsque l'application est fortement sollicitée, ou que l'application se dégrade élégamment dans de telles circonstances.
6.4.1	Vérifiez 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 et détruire les secrets de manière sécurisée.
6.4.2	Vérifiez que le matériel clé n'est pas exposé à l'application mais utilise plutôt un module de sécurité isolé comme un coffre-fort pour les opérations cryptographiques.
7.1.1	Vérifiez que l'application ne consigne pas les identifiants ou les détails de paiement. Les jetons de session ne doivent être stockés dans les journaux que sous une forme irréversible et hachée.
7.1.2	Vérifiez que l'application ne consigne pas d'autres données sensibles telles que définies par les lois locales sur la confidentialité ou la politique de sécurité pertinente.
7.1.3	Vérifiez que l'application enregistre des événements pertinents pour la sécurité, y compris les événements d'authentification réussis et échoués, les échecs de contrôle d'accès, les échecs de désérialisation et les échecs de validation des entrées.
7.1.4	Vérifiez que chaque événement de journalisation inclut les informations nécessaires qui permettraient une enquête détaillée de la chronologie lorsqu'un événement se produit.
7.3.1	Vérifiez que tous les composants de journalisation codent correctement les données pour prévenir l'injection de journaux.
7.3.3	Vérifiez que les journaux de sécurité sont protégés contre l'accès et la modification non autorisés.
7.4.1	Vérifiez qu'un message générique s'affiche lorsqu'une erreur inattendue ou sensible à la sécurité se produit, potentiellement avec un ID unique que le personnel de support peut utiliser pour enquêter.
7.4.2	Vérifiez que la gestion des exceptions (ou un équivalent fonctionnel) est utilisée dans l'ensemble de la base de code pour tenir compte des conditions d'erreur attendues et inattendues.
7.4.3	Vérifiez qu'un gestionnaire d'erreurs "dernier recours" est défini qui attrapera toutes les exceptions non gérées.
8.1.1	Vérifiez que l'application protège les données sensibles contre la mise en cache dans les composants du serveur tels que les équilibreurs de charge et les caches d'application.
8.1.2	Vérifiez que toutes les copies mises en cache ou temporaires de données sensibles stockées sur le serveur sont protégées contre l'accès non autorisé ou purgées/invalidées après que l'utilisateur autorisé a accédé aux données sensibles.
8.1.3	Vérifiez que l'application minimise le nombre de paramètres dans une demande, tels que les champs cachés, les variables Ajax, les cookies et les valeurs d'en-tête.
8.1.4	Vérifiez que l'application peut détecter et alerter sur un nombre anormal de demandes, par exemple par IP, utilisateur, total par heure ou par jour, ou tout ce qui a du sens pour l'application.
8.3.1	Vérifiez que les données sensibles sont envoyées au serveur dans le corps du message HTTP ou les en-têtes, et que les paramètres de la chaîne de requête de n'importe quel verbe HTTP ne contiennent pas de données sensibles.
8.3.6	Vérifiez que les informations sensibles contenues dans la mémoire sont écrasées dès qu'elles ne sont plus nécessaires pour atténuer les attaques de vidage de mémoire, en utilisant des zéros ou des données aléatoires.
8.3.7	Vérifiez que les informations sensibles ou privées qui doivent être cryptées le sont à l'aide d'algorithmes approuvés qui assurent à la fois la confidentialité et l'intégrité.
9.1.1	Vérifiez que TLS est utilisé pour toutes les connexions client, et ne revient pas à des communications non sécurisées ou non cryptées.
9.1.3	Vérifiez que seules les versions les plus récentes recommandées du protocole TLS sont activées, telles que TLS 1.2 et TLS 1.3. La dernière version du protocole TLS devrait être l'option privilégiée.
9.2.1	Vérifiez que les connexions vers et depuis le serveur utilisent des certificats TLS de confiance. Lorsque des certificats générés en interne ou auto-signés sont utilisés, le serveur doit être configuré pour ne faire confiance qu'à des AC internes spécifiques et à des certificats auto-signés spécifiques. Tous les autres devraient être rejetés.
9.2.2	Vérifiez que les communications cryptées telles que TLS sont utilisées pour toutes les connexions entrantes et sortantes, y compris pour les ports de gestion, la surveillance, l'authentification, les appels API ou de service web, la base de données, le cloud, sans serveur, le mainframe, les connexions externes et partenaires. Le serveur ne doit pas revenir à des protocoles non sécurisés ou non cryptés.
9.2.3	Vérifiez que toutes les connexions cryptées vers des systèmes externes impliquant des informations ou des fonctions sensibles sont authentifiées.
10.2.1	Vérifiez que le code source de l'application et les bibliothèques tierces ne contiennent pas de capacités non autorisées de retour à la maison par téléphone ou de collecte de données. Lorsqu'une telle fonctionnalité existe, obtenez la permission de l'utilisateur pour qu'elle fonctionne avant de collecter des données.
10.2.2	Vérifiez que l'application ne demande pas d'autorisations inutiles ou excessives pour des fonctionnalités ou des capteurs liés à la confidentialité, tels que les contacts, les caméras, les microphones ou la localisation.
10.2.3.	Vérifiez que le code source de l'application et les bibliothèques tierces ne contiennent pas de portes dérobées, telles que des comptes ou des clés codés en dur ou supplémentaires non documentés, l'obfuscation de code, des blobs binaires non documentés, des rootkits, ou de l'anti-débogage, des fonctionnalités de débogage non sécurisées, ou toute autre fonctionnalité obsolète, non sécurisée ou cachée qui pourrait être utilisée de manière malveillante si elle était découverte.
10.2.4	Vérifiez que le code source de l'application et les bibliothèques tierces ne contiennent pas de bombes à retardement en recherchant des fonctions liées à la date et à l'heure.
10.2.5	Vérifiez que le code source de l'application et les bibliothèques tierces ne contiennent pas de code malveillant, comme des attaques de type salami, des contournements de logique ou des bombes logiques.
10.2.6	Vérifiez que le code source de l'application et les bibliothèques tierces ne contiennent pas d'Easter eggs ou toute autre fonctionnalité potentiellement indésirable.
(10.3.1)	Vérifiez que si l'application dispose d'une fonction de mise à jour automatique côté client ou serveur, les mises à jour doivent être obtenues via des canaux sécurisés et signées numériquement. Le code de mise à jour doit valider la signature numérique de la mise à jour avant de l'installer ou de l'exécuter.
10.3.2	Vérifiez que l'application utilise des protections d'intégrité, telles que la signature de code ou l'intégrité des sous-ressources. L'application ne doit pas charger ou exécuter du code provenant de sources non fiables, comme le chargement de includes, de modules, de plugins, de code ou de bibliothèques provenant de sources non fiables ou d'Internet.
10.3.3	Vérifiez que l'application est protégée contre les prises de contrôle de sous-domaines si l'application dépend des entrées DNS ou des sous-domaines DNS, tels que les noms de domaine expirés, les pointeurs DNS obsolètes ou les CNAMEs, les projets expirés dans les dépôts publics de code source, ou les API cloud transitoires, les fonctions sans serveur, ou les compartiments de stockage (autogen-bucket-id.cloud.example.com) ou similaires. Les protections peuvent inclure la vérification régulière de l'expiration ou du changement des noms DNS utilisés par les applications.
11.1.1	Vérifiez que l'application ne traitera les flux de logique d'entreprise pour le même utilisateur que dans l'ordre séquentiel des étapes et sans sauter d'étapes.
11.1.2	Vérifiez que l'application ne traitera que les flux de logique d'entreprise avec toutes les étapes traitées en temps humain réaliste, c'est-à-dire que les transactions ne sont pas soumises trop rapidement.
11.1.3	Vérifiez que l'application a des limites appropriées pour des actions ou transactions commerciales spécifiques qui sont correctement appliquées sur une base par utilisateur.
11.1.4	Vérifiez que l'application dispose de contrôles anti-automatisation pour se protéger contre les appels excessifs tels que l'exfiltration massive de données, les demandes de logique d'entreprise, les téléchargements de fichiers ou les attaques par déni de service.
11.1.5	Vérifiez que l'application a des limites de logique commerciale ou une validation pour se protéger contre les risques ou menaces commerciales probables, identifiés à l'aide de la modélisation des menaces ou de méthodologies similaires.
11.1.6	Vérifiez que l'application ne souffre pas de problèmes de 'Time Of Check to Time Of Use' (TOCTOU) ou d'autres conditions de concurrence pour des opérations sensibles.
12.1.1	Vérifiez que l'application n'acceptera pas de gros fichiers qui pourraient remplir le stockage ou provoquer un déni de service.
12.1.3	Vérifiez qu'un quota de taille de fichier et un nombre maximum de fichiers par utilisateur sont appliqués pour garantir qu'un seul utilisateur ne peut pas remplir le stockage avec trop de fichiers, ou des fichiers excessivement volumineux.
12.3.1	Vérifiez que les métadonnées de nom de fichier soumises par l'utilisateur ne sont pas utilisées directement par les systèmes de fichiers du système ou du framework et qu'une API URL est utilisée pour se protéger contre la traversée de chemin.
12.3.2	Vérifiez que les métadonnées de nom de fichier soumises par l'utilisateur sont validées ou ignorées pour empêcher la divulgation, la création, la mise à jour ou la suppression de fichiers locaux (LFI).
12.3.3	Vérifiez que les métadonnées de nom de fichier soumises par l'utilisateur sont validées ou ignorées pour empêcher la divulgation ou l'exécution de fichiers distants via des attaques d'inclusion de fichiers distants (RFI) ou de falsification de requêtes côté serveur (SSRF).
12.3.4	Vérifiez que l'application protège contre le téléchargement de fichiers réfléchissants (RFD) en validant ou en ignorant les noms de fichiers soumis par l'utilisateur dans un JSON, JSONP, ou paramètre URL, l'en-tête de type de contenu de la réponse doit être défini sur text/plain, et l'en-tête de disposition de contenu doit avoir un nom de fichier fixe.
12.3.5	Vérifiez que les métadonnées de fichiers non fiables ne sont pas utilisées directement avec l'API système ou les bibliothèques, pour se protéger contre l'injection de commandes OS.
12.3.6	Vérifiez que l'application n'inclut pas et n'exécute pas de fonctionnalités provenant de sources non fiables, telles que des réseaux de distribution de contenu non vérifiés, des bibliothèques JavaScript, des bibliothèques npm de noeud, ou des DLL côté serveur.
12.4.1	Vérifiez que les fichiers obtenus à partir de sources non fiables sont stockés en dehors de la racine du web, avec des permissions limitées.
12.5.1	Vérifiez que la couche web est configurée pour ne servir que des fichiers avec des extensions de fichiers spécifiques afin d'éviter une fuite involontaire d'informations et de code source. Par exemple, les fichiers de sauvegarde (par exemple, .bak), les fichiers de travail temporaires (par exemple, .swp), les fichiers compressés (.zip, .tar.gz, etc.) et autres extensions couramment utilisées par les éditeurs devraient être bloqués sauf si nécessaire.
12.5.2	Vérifiez que les demandes directes aux fichiers téléchargés ne seront jamais exécutées en tant que contenu HTML/JavaScript.
12.6.1	Vérifiez que le serveur web ou d'application est configuré avec une liste d'autorisation de ressources ou de systèmes auxquels le serveur peut envoyer des demandes ou charger des données/fichiers.
13.1.1	Vérifiez que tous les composants de l'application utilisent les mêmes encodages et analyseurs pour éviter les attaques d'analyse qui exploitent différents comportements d'analyse d'URI ou de fichiers qui pourraient être utilisés dans les attaques SSRF et RFI.
13.1.3	Vérifiez que les URL de l'API n'exposent pas d'informations sensibles, telles que la clé de l'API, les jetons de session, etc.
13.1.4	Vérifiez que les décisions d'autorisation sont prises à la fois au niveau de l'URI, appliquées par la sécurité programmatique ou déclarative au niveau du contrôleur ou du routeur, et au niveau de la ressource, appliquées par les permissions basées sur le modèle.
13.1.5	Vérifiez que les demandes contenant des types de contenu inattendus ou manquants sont rejetées avec des en-têtes appropriés (statut de réponse HTTP 406 Inacceptable ou 415 Type de média non pris en charge).
13.2.1	Vérifiez que les méthodes HTTP RESTful activées sont un choix valide pour l'utilisateur ou l'action, comme empêcher les utilisateurs normaux d'utiliser DELETE ou PUT sur une API ou des ressources protégées.
13.2.2	Vérifiez que la validation du schéma JSON est en place et vérifiée avant d'accepter une entrée.
13.2.3	Vérifiez que les services Web RESTful qui utilisent des cookies sont protégés contre la falsification de requête inter-site grâce à l'utilisation d'au moins l'un des éléments suivants : le modèle de double envoi de cookie, les jetons CSRF, ou les vérifications d'en-tête de requête d'origine.
13.2.5	Vérifiez que les services REST vérifient explicitement que le Content-Type entrant est celui attendu, comme application/xml ou application/json.
13.2.6	Vérifiez que les en-têtes de message et la charge utile sont fiables et n'ont pas été modifiés pendant le transit. Exiger un cryptage fort pour le transport (TLS uniquement) peut être suffisant dans de nombreux cas car il fournit à la fois une protection de la confidentialité et de l'intégrité. Les signatures numériques par message peuvent fournir une assurance supplémentaire en plus des protections de transport pour les applications à haute sécurité, mais elles apportent avec elles une complexité supplémentaire et des risques à peser contre les avantages.
13.3.1	Vérifiez que la validation du schéma XSD a lieu pour garantir un document XML correctement formé, suivie de la validation de chaque champ d'entrée avant toute manipulation de ces données.
13.3.2	Vérifiez que la charge utile du message est signée à l'aide de WS-Security pour garantir un transport fiable entre le client et le service.
13.4.1	Vérifiez qu'une liste blanche de requêtes ou une combinaison de limitation de profondeur et de limitation de quantité est utilisée pour prévenir le déni de service (DoS) de GraphQL ou de l'expression de la couche de données en raison de requêtes coûteuses et imbriquées. Pour des scénarios plus avancés, l'analyse des coûts de requête devrait être utilisée.
14.1.3	Vérifiez que la configuration du serveur est renforcée conformément aux recommandations du serveur d'applications et des cadres utilisés.
14.2.2	Vérifiez que toutes les fonctionnalités inutiles, la documentation, les applications d'exemple et les configurations sont supprimées.
14.2.3	Vérifiez que si les actifs d'application, tels que les bibliothèques JavaScript, CSS ou les polices Web, sont hébergés en externe sur un réseau de diffusion de contenu (CDN) ou un fournisseur externe, l'intégrité des sous-ressources (SRI) est utilisée pour valider l'intégrité de l'actif.
14.2.4	Vérifiez que les composants tiers proviennent de dépôts prédéfinis, de confiance et constamment maintenus.
14.3.2	14.3.2 - Vérifiez que les modes de débogage du serveur web ou de l'application et du cadre d'application sont désactivés en production pour éliminer les fonctionnalités de débogage, les consoles de développeur et les divulgations de sécurité non intentionnelles.
14.3.3	Vérifiez que les en-têtes HTTP ou une partie de la réponse HTTP n'exposent pas d'informations détaillées sur la version des composants du système.
14.4.1	Vérifiez que chaque réponse HTTP contient un en-tête Content-Type. Spécifiez également un ensemble de caractères sûr (par exemple, UTF-8, ISO-8859-1) si les types de contenu sont text/*, /+xml et application/xml. Le contenu doit correspondre à l'en-tête Content-Type fourni.
14.4.2	Vérifiez que toutes les réponses de l'API contiennent un en-tête Content-Disposition: attachment; filename='api.json' (ou un autre nom de fichier approprié pour le type de contenu).
14.4.3	Vérifiez qu'un en-tête de réponse de politique de sécurité de contenu (CSP) est en place qui aide à atténuer l'impact des attaques XSS comme les vulnérabilités d'injection HTML, DOM, JSON et JavaScript.
14.4.4	Vérifiez que toutes les réponses contiennent un en-tête X-Content-Type-Options: nosniff.
14.4.5	Vérifiez qu'un en-tête Strict-Transport-Security est inclus dans toutes les réponses et pour tous les sous-domaines, comme Strict-Transport-Security: max-age=15724800; includeSubdomains.
14.4.6	Vérifiez qu'un en-tête de politique de référence approprié est inclus pour éviter d'exposer des informations sensibles dans l'URL via l'en-tête de référence à des parties non fiables.
14.4.7	Vérifiez que le contenu d'une application web ne peut pas être intégré par défaut dans un site tiers et que l'intégration des ressources exactes n'est autorisée que là où c'est nécessaire en utilisant des en-têtes de réponse Content-Security-Policy : frame-ancestors et X-Frame-Options appropriés.
14.5.1	Vérifiez que le serveur d'application n'accepte que les méthodes HTTP utilisées par l'application/API, y compris les OPTIONS de pré-vol, et enregistre/alerte sur toute demande qui n'est pas valide pour le contexte de l'application.
14.5.2	Vérifiez que l'en-tête d'origine fourni n'est pas utilisé pour l'authentification ou les décisions de contrôle d'accès, car l'en-tête d'origine peut facilement être modifié par un attaquant.
14.5.3	Vérifiez que l'en-tête Access-Control-Allow-Origin de partage de ressources entre origines (CORS) utilise une liste stricte de domaines et de sous-domaines de confiance à comparer et ne prend pas en charge l'origine 'null'.
14.5.4	Vérifiez que les en-têtes HTTP ajoutés par un proxy de confiance ou des appareils SSO, tels qu'un jeton porteur, sont authentifiés par l'application.

1.2.1

Vérifiez l'utilisation de comptes système d'exploitation uniques ou spéciaux à faibles privilèges pour tous les composants, services et serveurs d'application.

1.2.2

Vérifiez que les communications entre les composants de l'application, y compris les API, les intergiciels et les couches de données, sont authentifiées. Les composants devraient avoir les privilèges nécessaires les plus restreints possibles.

1.2.3

Vérifiez que l'application utilise un seul mécanisme d'authentification approuvé qui est connu pour être sécurisé, peut être étendu pour inclure une authentification forte, et dispose d'une surveillance et d'un enregistrement suffisants pour détecter les abus de compte ou les violations.

1.2.4

Vérifiez que tous les chemins d'authentification et les API de gestion d'identité mettent en œuvre une force de contrôle de sécurité d'authentification cohérente, de sorte qu'il n'y ait pas d'alternatives plus faibles en fonction du risque de l'application.

1.4.4

Vérifiez que l'application utilise un mécanisme de contrôle d'accès unique et bien vérifié pour accéder aux données et ressources protégées. Toutes les demandes doivent passer par ce seul mécanisme pour éviter le copier-coller ou les chemins alternatifs non sécurisés.

1.4.5

Vérifiez que le contrôle d'accès basé sur les attributs ou les fonctionnalités est utilisé, où le code vérifie l'autorisation de l'utilisateur pour une fonctionnalité/élément de données plutôt que simplement leur rôle. Les autorisations devraient toujours être attribuées en utilisant des rôles.

1.5.2

Vérifiez que la sérialisation n'est pas utilisée lors de la communication avec des clients non fiables. Si cela n'est pas possible, assurez-vous que des contrôles d'intégrité adéquats (et éventuellement un chiffrement si des données sensibles sont envoyées) sont appliqués pour prévenir les attaques de désérialisation, y compris l'injection d'objets.

1.5.3

Vérifiez que la validation des entrées est appliquée sur une couche de service de confiance.

1.5.4

Vérifiez que le codage de sortie se produit près de ou par l'interprète pour lequel il est destiné.

1.6.2

Vérifiez que les consommateurs de services cryptographiques protègent le matériel clé et autres secrets en utilisant des coffres-forts de clés ou des alternatives basées sur l'API.

1.6.3

Vérifiez que toutes les clés et les mots de passe sont remplaçables et font partie d'un processus bien défini pour re-chiffrer les données sensibles.

1.6.4

Vérifiez que l'architecture traite les secrets côté client - tels que les clés symétriques, les mots de passe ou les jetons API - comme non sécurisés et ne les utilise jamais pour protéger ou accéder à des données sensibles.

1.9.1

Vérifiez que l'application chiffre les communications entre les composants, en particulier lorsque ces composants se trouvent dans différents conteneurs, systèmes, sites ou fournisseurs de cloud.

1.9.2

Vérifiez que les composants de l'application vérifient l'authenticité de chaque côté d'un lien de communication pour prévenir les attaques de type intermédiaire. Par exemple, les composants de l'application devraient valider les certificats TLS et les chaînes.

1.11.2

Vérifiez que tous les flux de logique commerciale à haute valeur, y compris l'authentification, la gestion des sessions et le contrôle d'accès, ne partagent pas d'état non synchronisé.

1.11.3

Vérifiez que tous les flux de logique d'entreprise à haute valeur, y compris l'authentification, la gestion des sessions et le contrôle d'accès, sont à l'épreuve des threads et résistent aux conditions de course entre le moment de la vérification et le moment de l'utilisation.

1.14.6

Vérifiez que l'application n'utilise pas de technologies côté client non prises en charge, non sécurisées ou obsolètes telles que les plugins NSAPI, Flash, Shockwave, ActiveX, Silverlight, NACL ou les applets Java côté client.

2.1.1

Vérifiez que les mots de passe définis par l'utilisateur ont au moins 12 caractères de longueur (après que plusieurs espaces soient combinés).

2.1.2

Vérifiez que les mots de passe d'au moins 64 caractères sont autorisés, et que les mots de passe de plus de 128 caractères sont refusés.

2.2.1

Vérifiez que les contrôles anti-automatisation sont efficaces pour atténuer les tests de violation de crédentials, les attaques par force brute et les attaques de verrouillage de compte. Ces contrôles incluent le blocage des mots de passe les plus couramment violés, les verrouillages temporaires, la limitation du taux, le CAPTCHA, des délais de plus en plus longs entre les tentatives, les restrictions d'adresse IP, ou des restrictions basées sur le risque telles que l'emplacement, la première connexion sur un appareil, les tentatives récentes de déverrouillage du compte, ou similaires. Vérifiez qu'il n'est pas possible d'avoir plus de 100 tentatives échouées par heure sur un seul compte.

2.2.2

Vérifiez que l'utilisation d'authentificateurs faibles (tels que les SMS et les emails) est limitée à la vérification secondaire et à l'approbation des transactions, et non comme un remplacement pour des méthodes d'authentification plus sécurisées. Vérifiez que des méthodes plus fortes sont proposées avant les méthodes faibles, que les utilisateurs sont conscients des risques, ou que des mesures appropriées sont en place pour limiter les risques de compromission de compte.

2.2.4

Vérifiez la résistance à l'usurpation d'identité contre le hameçonnage, comme l'utilisation de l'authentification à plusieurs facteurs, des dispositifs cryptographiques avec intention (comme des clés connectées avec une pression pour authentifier), ou à des niveaux AAL plus élevés, des certificats côté client.

2.2.5

Vérifiez que là où un fournisseur de services d'identification (CSP) et l'application vérifiant l'authentification sont séparés, un TLS mutuellement authentifié est en place entre les deux points d'extrémité.

2.2.6

Vérifiez la résistance à la relecture grâce à l'utilisation obligatoire de dispositifs de mots de passe à usage unique (OTP), d'authentificateurs cryptographiques ou de codes de recherche.

2.3.1

Vérifiez que les mots de passe initiaux ou les codes d'activation générés par le système DOIVENT être générés de manière aléatoire et sécurisée, DOIVENT comporter au moins 6 caractères et PEUVENT contenir des lettres et des chiffres, et expirer après une courte période de temps. Ces secrets initiaux ne doivent pas être autorisés à devenir le mot de passe à long terme.

2.4.1

Vérifiez que les mots de passe sont stockés sous une forme résistante aux attaques hors ligne. Les mots de passe DOIVENT être salés et hachés en utilisant une fonction de dérivation de clé unidirectionnelle ou de hachage de mot de passe approuvée. Les fonctions de dérivation de clé et de hachage de mot de passe prennent un mot de passe, un sel et un facteur de coût en entrée lors de la génération d'un hachage de mot de passe.

2.4.2

Vérifiez que le sel a une longueur d'au moins 32 bits et qu'il est choisi arbitrairement pour minimiser les collisions de valeurs de sel parmi les hachages stockés. Pour chaque identifiant, une valeur de sel unique et le hachage résultant DOIVENT être stockés.

2.4.3

Vérifiez que si PBKDF2 est utilisé, le nombre d'itérations DEVRAIT être aussi grand que les performances du serveur de vérification le permettent, généralement au moins 100 000 itérations.

2.4.4

Vérifiez que si bcrypt est utilisé, le facteur de travail DEVRAIT être aussi grand que les performances du serveur de vérification le permettent, avec un minimum de 10.

2.4.5

Vérifiez qu'une itération supplémentaire d'une fonction de dérivation de clé est effectuée, en utilisant une valeur de sel qui est secrète et connue uniquement du vérificateur. Générez la valeur de sel en utilisant un générateur de bits aléatoires approuvé [SP 800-90Ar1] et fournissez au moins la force de sécurité minimale spécifiée dans la dernière révision de SP 800-131A. La valeur secrète du sel DOIT être stockée séparément des mots de passe hachés (par exemple, dans un dispositif spécialisé comme un module de sécurité matériel).

2.5.1

Vérifiez qu'un secret d'activation ou de récupération initial généré par le système n'est pas envoyé en clair à l'utilisateur.

2.5.2

Vérifiez que les indices de mot de passe ou l'authentification basée sur la connaissance (soi-disant questions secrètes) ne sont pas présents.

2.5.3

Vérifiez que la récupération des informations d'identification du mot de passe ne révèle en aucun cas le mot de passe actuel.

2.5.4

Vérifiez que les comptes partagés ou par défaut ne sont pas présents (par exemple, root, admin, ou sa).

2.6.1

Vérifiez que les secrets de recherche ne peuvent être utilisés qu'une seule fois.

2.6.2

Vérifiez que les secrets de recherche ont une aléatoire suffisante (112 bits d'entropie), ou si moins de 112 bits d'entropie, salés avec un sel unique et aléatoire de 32 bits et hachés avec un hachage unidirectionnel approuvé.

2.6.3

Vérifiez que les secrets de recherche résistent aux attaques hors ligne, comme les valeurs prévisibles.

2.10.1

Vérifiez que les secrets intra-service ne dépendent pas de justificatifs d'identité immuables tels que les mots de passe, les clés API ou les comptes partagés avec un accès privilégié.

2.10.2

Vérifiez que si des mots de passe sont requis pour l'authentification du service, le compte de service utilisé n'est pas une authentification par défaut. (par exemple, root/root ou admin/admin sont par défaut dans certains services lors de l'installation).

2.10.3

Vérifiez que les mots de passe sont stockés avec une protection suffisante pour prévenir les attaques de récupération hors ligne, y compris l'accès au système local.

2.10.4

Vérifiez que les mots de passe, les intégrations avec les bases de données et les systèmes tiers, les graines et les secrets internes, et les clés API sont gérés de manière sécurisée et ne sont pas inclus dans le code source ou stockés dans les dépôts de code source. Un tel stockage DEVRAIT résister aux attaques hors ligne. L'utilisation d'un magasin de clés logiciel sécurisé (L1), d'un TPM matériel, ou d'un HSM (L3) est recommandée pour le stockage des mots de passe.

3.1.1

Vérifiez que l'application ne révèle jamais les jetons de session dans les paramètres d'URL.

3.2.1

Vérifiez que l'application génère un nouveau jeton de session lors de l'authentification de l'utilisateur.

3.2.2

Vérifiez que les jetons de session possèdent au moins 64 bits d'entropie.

3.2.3

Vérifiez que l'application ne stocke les jetons de session dans le navigateur qu'en utilisant des méthodes sécurisées telles que des cookies correctement sécurisés (voir section 3.4) ou le stockage de session HTML 5.

3.2.4

Vérifiez que les jetons de session sont générés en utilisant des algorithmes cryptographiques approuvés.

3.3.1

Vérifiez que la déconnexion et l'expiration invalident le jeton de session, de sorte que le bouton de retour ou une partie dépendante en aval ne reprenne pas une session authentifiée, y compris entre les parties dépendantes.

3.3.2

Si les authentificateurs permettent aux utilisateurs de rester connectés, vérifiez que la ré-authentification se produit périodiquement, à la fois lorsqu'elle est activement utilisée ou après une période d'inactivité.

3.3.3

Vérifiez que l'application offre l'option de terminer toutes les autres sessions actives après un changement de mot de passe réussi (y compris le changement via la réinitialisation/récupération du mot de passe), et que cela est efficace à travers l'application, la connexion fédérée (si présente), et toutes les parties qui s'y fient.

3.3.4

Vérifiez que les utilisateurs sont capables de voir et (après avoir ressaisi leurs identifiants de connexion) de se déconnecter de toutes les sessions et tous les appareils actuellement actifs.

3.4.1

Vérifiez que les jetons de session basés sur les cookies ont l'attribut 'Secure' défini.

3.4.2

Vérifiez que les jetons de session basés sur les cookies ont l'attribut 'HttpOnly' défini

3.4.3

Vérifiez que les jetons de session basés sur les cookies utilisent l'attribut 'SameSite' pour limiter l'exposition aux attaques de falsification de requêtes inter-sites.

3.4.4

Vérifiez que les jetons de session basés sur les cookies utilisent le préfixe '__Host-' afin que les cookies ne soient envoyés qu'à l'hôte qui a initialement défini le cookie.

3.4.5

Vérifiez que si l'application est publiée sous un nom de domaine avec d'autres applications qui définissent ou utilisent des cookies de session susceptibles de divulguer les cookies de session, définissez l'attribut de chemin dans les jetons de session basés sur les cookies en utilisant le chemin le plus précis possible.

3.5.1

Vérifiez que l'application permet aux utilisateurs de révoquer les jetons OAuth qui forment des relations de confiance avec les applications liées.

3.5.2

Vérifiez que l'application utilise des jetons de session plutôt que des secrets et des clés API statiques, sauf avec les implémentations héritées.

3.5.3

Vérifiez que les jetons de session sans état utilisent des signatures numériques, le chiffrement et d'autres contre-mesures pour se protéger contre les attaques de falsification, d'enveloppement, de relecture, de chiffrement nul et de substitution de clé.

3.7.1

Vérifiez que l'application assure une session de connexion complète et valide ou nécessite une nouvelle authentification ou une vérification secondaire avant d'autoriser toute transaction sensible ou modification de compte.

4.1.1

Vérifiez que l'application applique les règles de contrôle d'accès sur une couche de service de confiance, surtout si le contrôle d'accès côté client est présent et pourrait être contourné.

4.1.2

Vérifiez que tous les attributs des utilisateurs et des données ainsi que les informations de politique utilisées par les contrôles d'accès ne peuvent pas être manipulés par les utilisateurs finaux à moins d'y être spécifiquement autorisés.

4.1.3

Vérifiez que le principe du moindre privilège existe - les utilisateurs ne devraient être en mesure d'accéder qu'aux fonctions, fichiers de données, URL, contrôleurs, services et autres ressources, pour lesquels ils possèdent une autorisation spécifique. Cela implique une protection contre le spoofing et l'élévation de privilège.

4.1.5

Vérifiez que les contrôles d'accès échouent de manière sécurisée, y compris lorsqu'une exception se produit.

4.2.1

Vérifiez que les données sensibles et les API sont protégées contre les attaques de référence d'objet direct non sécurisé (IDOR) visant la création, la lecture, la mise à jour et la suppression d'enregistrements, tels que la création ou la mise à jour de l'enregistrement de quelqu'un d'autre, la visualisation des enregistrements de tout le monde, ou la suppression de tous les enregistrements.

4.2.2

Vérifiez que l'application ou le cadre d'application applique un mécanisme anti-CSRF fort pour protéger les fonctionnalités authentifiées, et qu'un anti-automatisation ou anti-CSRF efficace protège les fonctionnalités non authentifiées.

4.3.2

Vérifiez que la navigation dans les répertoires est désactivée à moins qu'elle ne soit délibérément souhaitée. De plus, les applications ne devraient pas permettre la découverte ou la divulgation des métadonnées de fichiers ou de répertoires, tels que Thumbs.db, .DS_Store, les dossiers .git ou .svn.

5.1.1

Vérifiez que l'application a des défenses contre les attaques de pollution de paramètres HTTP, en particulier si le cadre de l'application ne fait aucune distinction quant à la source des paramètres de demande (GET, POST, cookies, en-têtes ou variables d'environnement).

5.1.2

Vérifiez que les cadres protègent contre les attaques de masse par affectation de paramètres, ou que l'application a des contre-mesures pour se protéger contre l'affectation de paramètres non sécurisée, comme marquer les champs privés ou similaires.

5.1.3

Vérifiez que toutes les entrées (champs de formulaire HTML, requêtes REST, paramètres URL, en-têtes HTTP, cookies, fichiers batch, flux RSS, etc.) sont validées en utilisant une validation positive (listes d'autorisation).

5.1.4

Vérifiez que les données structurées sont fortement typées et validées par rapport à un schéma défini, y compris les caractères autorisés, la longueur et le motif (par exemple, les numéros de carte de crédit, les adresses e-mail, les numéros de téléphone, ou la validation que deux champs liés sont raisonnables, comme vérifier que le quartier et le code postal correspondent).

5.1.5

Vérifiez que les redirections et les renvois d'URL n'autorisent que des destinations qui figurent sur une liste d'autorisation, ou affichez un avertissement lors de la redirection vers un contenu potentiellement non fiable.

5.2.1

Vérifiez que toutes les entrées HTML non fiables provenant d'éditeurs WYSIWYG ou similaires sont correctement assainies avec une bibliothèque d'assainissement HTML ou une fonctionnalité de framework.

5.2.2

Vérifiez que les données non structurées sont assainies pour appliquer des mesures de sécurité telles que les caractères autorisés et la longueur.

5.2.3

Vérifiez 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.

5.2.4

Vérifiez que l'application évite l'utilisation de eval() ou d'autres fonctionnalités d'exécution de code dynamique. Là où il n'y a pas d'alternative, toute entrée utilisateur incluse doit être assainie ou mise en bac à sable avant d'être exécutée.

5.2.6

Vérifiez que l'application se protège contre les attaques SSRF, en validant ou en assainissant les données non fiables ou les métadonnées de fichiers HTTP, telles que les noms de fichiers et les champs d'entrée d'URL, et utilise des listes d'autorisation de protocoles, de domaines, de chemins et de ports.

5.2.7

Vérifiez que l'application assainit, désactive ou met en bac à sable le contenu scriptable fourni par l'utilisateur en Scalable Vector Graphics (SVG), en particulier en ce qui concerne les XSS résultant de scripts en ligne, et foreignObject.

5.2.8

Vérifiez que l'application assainit, désactive ou met en bac à sable le contenu fourni par l'utilisateur pouvant être scripté ou basé sur un langage de modèle d'expression, tel que Markdown, CSS ou feuilles de style XSL, BBCode, ou similaire.

5.3.1

Vérifiez que le codage de sortie est pertinent pour l'interprète et le contexte requis. Par exemple, utilisez des encodeurs spécifiquement pour les valeurs HTML, les attributs HTML, JavaScript, les paramètres URL, les en-têtes HTTP, SMTP, et autres selon le contexte requis, en particulier à partir d'entrées non fiables (par exemple, des noms avec Unicode ou des apostrophes, comme ねこou O'Hara).

5.3.2

Vérifiez que le codage de sortie préserve l'ensemble de caractères et les paramètres régionaux choisis par l'utilisateur, de sorte que tout point de caractère Unicode est valide et géré en toute sécurité.

5.3.3

Vérifiez que l'échappement de sortie conscient du contexte, de préférence automatisé - ou au pire, manuel - protège contre les XSS reflétés, stockés et basés sur le DOM.

5.3.4

Vérifiez que la sélection de données ou les requêtes de base de données (par exemple, SQL, HQL, ORM, NoSQL) utilisent des requêtes paramétrées, des ORM, des cadres d'entités, ou sont autrement protégées contre les attaques d'injection de base de données.

5.3.5

Vérifiez que lorsque des mécanismes paramétrés ou plus sûrs ne sont pas présents, un codage de sortie spécifique au contexte est utilisé pour se protéger contre les attaques par injection, comme l'utilisation de l'échappement SQL pour se protéger contre l'injection SQL.

5.3.6

Vérifiez que l'application protège contre les attaques par injection JSON, les attaques par évaluation JSON et l'évaluation d'expressions JavaScript.

5.3.7

Vérifiez que l'application protège contre les vulnérabilités d'injection LDAP, ou que des contrôles de sécurité spécifiques pour prévenir l'injection LDAP ont été mis en place.

5.3.8

Vérifiez que l'application se protège contre l'injection de commandes OS et que les appels au système d'exploitation utilisent des requêtes OS paramétrées ou utilisent un codage de sortie de ligne de commande contextuel.

5.3.9

Vérifiez que l'application protège contre les attaques d'inclusion de fichiers locaux (LFI) ou d'inclusion de fichiers distants (RFI).

5.3.10

Vérifiez que l'application se protège contre les attaques par injection XPath ou injection XML.

5.4.1

Vérifiez que l'application utilise une chaîne de mémoire sécurisée, une copie de mémoire plus sûre et une arithmétique de pointeur pour détecter ou prévenir les débordements de pile, de tampon ou de tas.

5.4.2

Vérifiez que les chaînes de format ne prennent pas d'entrée potentiellement hostile et sont constantes.

5.4.3

Vérifiez que les techniques de validation de signe, de plage et d'entrée sont utilisées pour prévenir les débordements d'entiers.

5.5.1

Vérifiez que les objets sérialisés utilisent des contrôles d'intégrité ou sont chiffrés pour prévenir la création d'objets hostiles ou la falsification de données.

5.5.2

Vérifiez que l'application restreint correctement les analyseurs XML à n'utiliser que la configuration la plus restrictive possible et à garantir que les fonctionnalités dangereuses telles que la résolution d'entités externes sont désactivées pour prévenir les attaques XML eXternal Entity (XXE).

5.5.3

Vérifiez que la désérialisation de données non fiables est évitée ou protégée à la fois dans le code personnalisé et dans les bibliothèques tierces (telles que les analyseurs JSON, XML et YAML).

5.5.4

Vérifiez que lors de l'analyse JSON dans les navigateurs ou les backends basés sur JavaScript, JSON.parse est utilisé pour analyser le document JSON. N'utilisez pas eval() pour analyser JSON.

6.1.1

Vérifiez que les données privées réglementées sont stockées de manière cryptée lorsqu'elles sont au repos, comme les informations personnelles identifiables (PII), les informations personnelles sensibles ou les données jugées susceptibles d'être soumises au RGPD de l'UE.

6.1.2

Vérifiez que les données de santé réglementées sont stockées de manière cryptée lorsqu'elles sont au repos, comme les dossiers médicaux, les détails des dispositifs médicaux ou les dossiers de recherche désanonymisés.

6.1.3

Vérifiez que les données financières réglementées sont stockées de manière cryptée lorsqu'elles sont au repos, telles que les comptes financiers, les défauts ou l'historique de crédit, les dossiers fiscaux, l'historique de paiement, les bénéficiaires ou les dossiers de marché ou de recherche désanonymisés.

6.2.1

Vérifiez que tous les modules cryptographiques échouent de manière sécurisée, et que les erreurs sont gérées de manière à ne pas permettre les attaques de Padding Oracle.

6.2.2.

Vérifiez que des algorithmes, modes et bibliothèques cryptographiques éprouvés par l'industrie ou approuvés par le gouvernement sont utilisés, au lieu d'une cryptographie codée sur mesure.

6.2.3

Vérifiez que le vecteur d'initialisation du chiffrement, la configuration du chiffre et les modes de bloc sont configurés de manière sécurisée en utilisant les derniers conseils.

6.2.4

Vérifiez que les nombres aléatoires, les algorithmes de chiffrement ou de hachage, les longueurs de clés, les tours, les chiffrements ou les modes, peuvent être reconfigurés, améliorés ou échangés à tout moment, pour se protéger contre les ruptures cryptographiques.

6.2.5

Vérifiez que les modes de blocs connus comme non sécurisés (c'est-à-dire ECB, etc.), les modes de remplissage (c'est-à-dire PKCS#1 v1.5, etc.), les chiffrements avec de petites tailles de blocs (c'est-à-dire Triple-DES, Blowfish, etc.) et les algorithmes de hachage faibles (c'est-à-dire MD5, SHA1, etc.) ne sont pas utilisés sauf si nécessaire pour la compatibilité descendante.

6.2.6

Vérifiez que les nonces, les vecteurs d'initialisation et les autres nombres à usage unique ne doivent pas être utilisés plus d'une fois avec une clé de chiffrement donnée. La méthode de génération doit être appropriée pour l'algorithme utilisé.

6.2.7

Vérifiez que les données cryptées sont authentifiées par des signatures, des modes de chiffrement authentifiés ou HMAC pour garantir que le texte chiffré n'est pas modifié par une partie non autorisée.

6.2.8

Vérifiez que toutes les opérations cryptographiques sont constantes, sans opérations de 'court-circuit' dans les comparaisons, les calculs ou les retours, pour éviter de divulguer des informations.

6.3.1

Vérifiez que tous les nombres aléatoires, les noms de fichiers aléatoires, les GUID aléatoires et les chaînes aléatoires sont générés à l'aide du générateur de nombres aléatoires sécurisé cryptographiquement approuvé du module cryptographique lorsque ces valeurs aléatoires sont censées ne pas être devinables par un attaquant.

6.3.2

Vérifiez que les GUID aléatoires sont créés en utilisant l'algorithme GUID v4 et un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé (CSPRNG). Les GUID créés à l'aide d'autres générateurs de nombres pseudo-aléatoires peuvent être prévisibles.

6.3.3

Vérifiez que des nombres aléatoires sont créés avec une entropie appropriée même lorsque l'application est fortement sollicitée, ou que l'application se dégrade élégamment dans de telles circonstances.

6.4.1

Vérifiez 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 et détruire les secrets de manière sécurisée.

6.4.2

Vérifiez que le matériel clé n'est pas exposé à l'application mais utilise plutôt un module de sécurité isolé comme un coffre-fort pour les opérations cryptographiques.

7.1.1

Vérifiez que l'application ne consigne pas les identifiants ou les détails de paiement. Les jetons de session ne doivent être stockés dans les journaux que sous une forme irréversible et hachée.

7.1.2

Vérifiez que l'application ne consigne pas d'autres données sensibles telles que définies par les lois locales sur la confidentialité ou la politique de sécurité pertinente.

7.1.3

Vérifiez que l'application enregistre des événements pertinents pour la sécurité, y compris les événements d'authentification réussis et échoués, les échecs de contrôle d'accès, les échecs de désérialisation et les échecs de validation des entrées.

7.1.4

Vérifiez que chaque événement de journalisation inclut les informations nécessaires qui permettraient une enquête détaillée de la chronologie lorsqu'un événement se produit.

7.3.1

Vérifiez que tous les composants de journalisation codent correctement les données pour prévenir l'injection de journaux.

7.3.3

Vérifiez que les journaux de sécurité sont protégés contre l'accès et la modification non autorisés.

7.4.1

Vérifiez qu'un message générique s'affiche lorsqu'une erreur inattendue ou sensible à la sécurité se produit, potentiellement avec un ID unique que le personnel de support peut utiliser pour enquêter.

7.4.2

Vérifiez que la gestion des exceptions (ou un équivalent fonctionnel) est utilisée dans l'ensemble de la base de code pour tenir compte des conditions d'erreur attendues et inattendues.

7.4.3

Vérifiez qu'un gestionnaire d'erreurs "dernier recours" est défini qui attrapera toutes les exceptions non gérées.

8.1.1

Vérifiez que l'application protège les données sensibles contre la mise en cache dans les composants du serveur tels que les équilibreurs de charge et les caches d'application.

8.1.2

Vérifiez que toutes les copies mises en cache ou temporaires de données sensibles stockées sur le serveur sont protégées contre l'accès non autorisé ou purgées/invalidées après que l'utilisateur autorisé a accédé aux données sensibles.

8.1.3

Vérifiez que l'application minimise le nombre de paramètres dans une demande, tels que les champs cachés, les variables Ajax, les cookies et les valeurs d'en-tête.

8.1.4

Vérifiez que l'application peut détecter et alerter sur un nombre anormal de demandes, par exemple par IP, utilisateur, total par heure ou par jour, ou tout ce qui a du sens pour l'application.

8.3.1

Vérifiez que les données sensibles sont envoyées au serveur dans le corps du message HTTP ou les en-têtes, et que les paramètres de la chaîne de requête de n'importe quel verbe HTTP ne contiennent pas de données sensibles.

8.3.6

Vérifiez que les informations sensibles contenues dans la mémoire sont écrasées dès qu'elles ne sont plus nécessaires pour atténuer les attaques de vidage de mémoire, en utilisant des zéros ou des données aléatoires.

8.3.7

Vérifiez que les informations sensibles ou privées qui doivent être cryptées le sont à l'aide d'algorithmes approuvés qui assurent à la fois la confidentialité et l'intégrité.

9.1.1

Vérifiez que TLS est utilisé pour toutes les connexions client, et ne revient pas à des communications non sécurisées ou non cryptées.

9.1.3

Vérifiez que seules les versions les plus récentes recommandées du protocole TLS sont activées, telles que TLS 1.2 et TLS 1.3. La dernière version du protocole TLS devrait être l'option privilégiée.

9.2.1

Vérifiez que les connexions vers et depuis le serveur utilisent des certificats TLS de confiance. Lorsque des certificats générés en interne ou auto-signés sont utilisés, le serveur doit être configuré pour ne faire confiance qu'à des AC internes spécifiques et à des certificats auto-signés spécifiques. Tous les autres devraient être rejetés.

9.2.2

Vérifiez que les communications cryptées telles que TLS sont utilisées pour toutes les connexions entrantes et sortantes, y compris pour les ports de gestion, la surveillance, l'authentification, les appels API ou de service web, la base de données, le cloud, sans serveur, le mainframe, les connexions externes et partenaires. Le serveur ne doit pas revenir à des protocoles non sécurisés ou non cryptés.

9.2.3

Vérifiez que toutes les connexions cryptées vers des systèmes externes impliquant des informations ou des fonctions sensibles sont authentifiées.

10.2.1

Vérifiez que le code source de l'application et les bibliothèques tierces ne contiennent pas de capacités non autorisées de retour à la maison par téléphone ou de collecte de données. Lorsqu'une telle fonctionnalité existe, obtenez la permission de l'utilisateur pour qu'elle fonctionne avant de collecter des données.

10.2.2

Vérifiez que l'application ne demande pas d'autorisations inutiles ou excessives pour des fonctionnalités ou des capteurs liés à la confidentialité, tels que les contacts, les caméras, les microphones ou la localisation.

10.2.3.

Vérifiez que le code source de l'application et les bibliothèques tierces ne contiennent pas de portes dérobées, telles que des comptes ou des clés codés en dur ou supplémentaires non documentés, l'obfuscation de code, des blobs binaires non documentés, des rootkits, ou de l'anti-débogage, des fonctionnalités de débogage non sécurisées, ou toute autre fonctionnalité obsolète, non sécurisée ou cachée qui pourrait être utilisée de manière malveillante si elle était découverte.

10.2.4

Vérifiez que le code source de l'application et les bibliothèques tierces ne contiennent pas de bombes à retardement en recherchant des fonctions liées à la date et à l'heure.

10.2.5

Vérifiez que le code source de l'application et les bibliothèques tierces ne contiennent pas de code malveillant, comme des attaques de type salami, des contournements de logique ou des bombes logiques.

10.2.6

Vérifiez que le code source de l'application et les bibliothèques tierces ne contiennent pas d'Easter eggs ou toute autre fonctionnalité potentiellement indésirable.

(10.3.1)

Vérifiez que si l'application dispose d'une fonction de mise à jour automatique côté client ou serveur, les mises à jour doivent être obtenues via des canaux sécurisés et signées numériquement. Le code de mise à jour doit valider la signature numérique de la mise à jour avant de l'installer ou de l'exécuter.

10.3.2

Vérifiez que l'application utilise des protections d'intégrité, telles que la signature de code ou l'intégrité des sous-ressources. L'application ne doit pas charger ou exécuter du code provenant de sources non fiables, comme le chargement de includes, de modules, de plugins, de code ou de bibliothèques provenant de sources non fiables ou d'Internet.

10.3.3

Vérifiez que l'application est protégée contre les prises de contrôle de sous-domaines si l'application dépend des entrées DNS ou des sous-domaines DNS, tels que les noms de domaine expirés, les pointeurs DNS obsolètes ou les CNAMEs, les projets expirés dans les dépôts publics de code source, ou les API cloud transitoires, les fonctions sans serveur, ou les compartiments de stockage (autogen-bucket-id.cloud.example.com) ou similaires. Les protections peuvent inclure la vérification régulière de l'expiration ou du changement des noms DNS utilisés par les applications.

11.1.1

Vérifiez que l'application ne traitera les flux de logique d'entreprise pour le même utilisateur que dans l'ordre séquentiel des étapes et sans sauter d'étapes.

11.1.2

Vérifiez que l'application ne traitera que les flux de logique d'entreprise avec toutes les étapes traitées en temps humain réaliste, c'est-à-dire que les transactions ne sont pas soumises trop rapidement.

11.1.3

Vérifiez que l'application a des limites appropriées pour des actions ou transactions commerciales spécifiques qui sont correctement appliquées sur une base par utilisateur.

11.1.4

Vérifiez que l'application dispose de contrôles anti-automatisation pour se protéger contre les appels excessifs tels que l'exfiltration massive de données, les demandes de logique d'entreprise, les téléchargements de fichiers ou les attaques par déni de service.

11.1.5

Vérifiez que l'application a des limites de logique commerciale ou une validation pour se protéger contre les risques ou menaces commerciales probables, identifiés à l'aide de la modélisation des menaces ou de méthodologies similaires.

11.1.6

Vérifiez que l'application ne souffre pas de problèmes de 'Time Of Check to Time Of Use' (TOCTOU) ou d'autres conditions de concurrence pour des opérations sensibles.

12.1.1

Vérifiez que l'application n'acceptera pas de gros fichiers qui pourraient remplir le stockage ou provoquer un déni de service.

12.1.3

Vérifiez qu'un quota de taille de fichier et un nombre maximum de fichiers par utilisateur sont appliqués pour garantir qu'un seul utilisateur ne peut pas remplir le stockage avec trop de fichiers, ou des fichiers excessivement volumineux.

12.3.1

Vérifiez que les métadonnées de nom de fichier soumises par l'utilisateur ne sont pas utilisées directement par les systèmes de fichiers du système ou du framework et qu'une API URL est utilisée pour se protéger contre la traversée de chemin.

12.3.2

Vérifiez que les métadonnées de nom de fichier soumises par l'utilisateur sont validées ou ignorées pour empêcher la divulgation, la création, la mise à jour ou la suppression de fichiers locaux (LFI).

12.3.3

Vérifiez que les métadonnées de nom de fichier soumises par l'utilisateur sont validées ou ignorées pour empêcher la divulgation ou l'exécution de fichiers distants via des attaques d'inclusion de fichiers distants (RFI) ou de falsification de requêtes côté serveur (SSRF).

12.3.4

Vérifiez que l'application protège contre le téléchargement de fichiers réfléchissants (RFD) en validant ou en ignorant les noms de fichiers soumis par l'utilisateur dans un JSON, JSONP, ou paramètre URL, l'en-tête de type de contenu de la réponse doit être défini sur text/plain, et l'en-tête de disposition de contenu doit avoir un nom de fichier fixe.

12.3.5

Vérifiez que les métadonnées de fichiers non fiables ne sont pas utilisées directement avec l'API système ou les bibliothèques, pour se protéger contre l'injection de commandes OS.

12.3.6

Vérifiez que l'application n'inclut pas et n'exécute pas de fonctionnalités provenant de sources non fiables, telles que des réseaux de distribution de contenu non vérifiés, des bibliothèques JavaScript, des bibliothèques npm de noeud, ou des DLL côté serveur.

12.4.1

Vérifiez que les fichiers obtenus à partir de sources non fiables sont stockés en dehors de la racine du web, avec des permissions limitées.

12.5.1

Vérifiez que la couche web est configurée pour ne servir que des fichiers avec des extensions de fichiers spécifiques afin d'éviter une fuite involontaire d'informations et de code source. Par exemple, les fichiers de sauvegarde (par exemple, .bak), les fichiers de travail temporaires (par exemple, .swp), les fichiers compressés (.zip, .tar.gz, etc.) et autres extensions couramment utilisées par les éditeurs devraient être bloqués sauf si nécessaire.

12.5.2

Vérifiez que les demandes directes aux fichiers téléchargés ne seront jamais exécutées en tant que contenu HTML/JavaScript.

12.6.1

Vérifiez que le serveur web ou d'application est configuré avec une liste d'autorisation de ressources ou de systèmes auxquels le serveur peut envoyer des demandes ou charger des données/fichiers.

13.1.1

Vérifiez que tous les composants de l'application utilisent les mêmes encodages et analyseurs pour éviter les attaques d'analyse qui exploitent différents comportements d'analyse d'URI ou de fichiers qui pourraient être utilisés dans les attaques SSRF et RFI.

13.1.3

Vérifiez que les URL de l'API n'exposent pas d'informations sensibles, telles que la clé de l'API, les jetons de session, etc.

13.1.4

Vérifiez que les décisions d'autorisation sont prises à la fois au niveau de l'URI, appliquées par la sécurité programmatique ou déclarative au niveau du contrôleur ou du routeur, et au niveau de la ressource, appliquées par les permissions basées sur le modèle.

13.1.5

Vérifiez que les demandes contenant des types de contenu inattendus ou manquants sont rejetées avec des en-têtes appropriés (statut de réponse HTTP 406 Inacceptable ou 415 Type de média non pris en charge).

13.2.1

Vérifiez que les méthodes HTTP RESTful activées sont un choix valide pour l'utilisateur ou l'action, comme empêcher les utilisateurs normaux d'utiliser DELETE ou PUT sur une API ou des ressources protégées.

13.2.2

Vérifiez que la validation du schéma JSON est en place et vérifiée avant d'accepter une entrée.

13.2.3

Vérifiez que les services Web RESTful qui utilisent des cookies sont protégés contre la falsification de requête inter-site grâce à l'utilisation d'au moins l'un des éléments suivants : le modèle de double envoi de cookie, les jetons CSRF, ou les vérifications d'en-tête de requête d'origine.

13.2.5

Vérifiez que les services REST vérifient explicitement que le Content-Type entrant est celui attendu, comme application/xml ou application/json.

13.2.6

Vérifiez que les en-têtes de message et la charge utile sont fiables et n'ont pas été modifiés pendant le transit. Exiger un cryptage fort pour le transport (TLS uniquement) peut être suffisant dans de nombreux cas car il fournit à la fois une protection de la confidentialité et de l'intégrité. Les signatures numériques par message peuvent fournir une assurance supplémentaire en plus des protections de transport pour les applications à haute sécurité, mais elles apportent avec elles une complexité supplémentaire et des risques à peser contre les avantages.

13.3.1

Vérifiez que la validation du schéma XSD a lieu pour garantir un document XML correctement formé, suivie de la validation de chaque champ d'entrée avant toute manipulation de ces données.

13.3.2

Vérifiez que la charge utile du message est signée à l'aide de WS-Security pour garantir un transport fiable entre le client et le service.

13.4.1

Vérifiez qu'une liste blanche de requêtes ou une combinaison de limitation de profondeur et de limitation de quantité est utilisée pour prévenir le déni de service (DoS) de GraphQL ou de l'expression de la couche de données en raison de requêtes coûteuses et imbriquées. Pour des scénarios plus avancés, l'analyse des coûts de requête devrait être utilisée.

14.1.3

Vérifiez que la configuration du serveur est renforcée conformément aux recommandations du serveur d'applications et des cadres utilisés.

14.2.2

Vérifiez que toutes les fonctionnalités inutiles, la documentation, les applications d'exemple et les configurations sont supprimées.

14.2.3

Vérifiez que si les actifs d'application, tels que les bibliothèques JavaScript, CSS ou les polices Web, sont hébergés en externe sur un réseau de diffusion de contenu (CDN) ou un fournisseur externe, l'intégrité des sous-ressources (SRI) est utilisée pour valider l'intégrité de l'actif.

14.2.4

Vérifiez que les composants tiers proviennent de dépôts prédéfinis, de confiance et constamment maintenus.

14.3.2

14.3.2 - Vérifiez que les modes de débogage du serveur web ou de l'application et du cadre d'application sont désactivés en production pour éliminer les fonctionnalités de débogage, les consoles de développeur et les divulgations de sécurité non intentionnelles.

14.3.3

Vérifiez que les en-têtes HTTP ou une partie de la réponse HTTP n'exposent pas d'informations détaillées sur la version des composants du système.

14.4.1

Vérifiez que chaque réponse HTTP contient un en-tête Content-Type. Spécifiez également un ensemble de caractères sûr (par exemple, UTF-8, ISO-8859-1) si les types de contenu sont text/*, /+xml et application/xml. Le contenu doit correspondre à l'en-tête Content-Type fourni.

14.4.2

Vérifiez que toutes les réponses de l'API contiennent un en-tête Content-Disposition: attachment; filename='api.json' (ou un autre nom de fichier approprié pour le type de contenu).

14.4.3

Vérifiez qu'un en-tête de réponse de politique de sécurité de contenu (CSP) est en place qui aide à atténuer l'impact des attaques XSS comme les vulnérabilités d'injection HTML, DOM, JSON et JavaScript.

14.4.4

Vérifiez que toutes les réponses contiennent un en-tête X-Content-Type-Options: nosniff.

14.4.5

Vérifiez qu'un en-tête Strict-Transport-Security est inclus dans toutes les réponses et pour tous les sous-domaines, comme Strict-Transport-Security: max-age=15724800; includeSubdomains.

14.4.6

Vérifiez qu'un en-tête de politique de référence approprié est inclus pour éviter d'exposer des informations sensibles dans l'URL via l'en-tête de référence à des parties non fiables.

14.4.7

Vérifiez que le contenu d'une application web ne peut pas être intégré par défaut dans un site tiers et que l'intégration des ressources exactes n'est autorisée que là où c'est nécessaire en utilisant des en-têtes de réponse Content-Security-Policy : frame-ancestors et X-Frame-Options appropriés.

14.5.1

Vérifiez que le serveur d'application n'accepte que les méthodes HTTP utilisées par l'application/API, y compris les OPTIONS de pré-vol, et enregistre/alerte sur toute demande qui n'est pas valide pour le contexte de l'application.

14.5.2

Vérifiez que l'en-tête d'origine fourni n'est pas utilisé pour l'authentification ou les décisions de contrôle d'accès, car l'en-tête d'origine peut facilement être modifié par un attaquant.

14.5.3

Vérifiez que l'en-tête Access-Control-Allow-Origin de partage de ressources entre origines (CORS) utilise une liste stricte de domaines et de sous-domaines de confiance à comparer et ne prend pas en charge l'origine 'null'.

14.5.4

Vérifiez que les en-têtes HTTP ajoutés par un proxy de confiance ou des appareils SSO, tels qu'un jeton porteur, sont authentifiés par l'application.

Rapport de vérification de la sécurité des applications OWASP

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

AppScan et la norme ASVS

Sections du règlement