Un lien trompeur, un droit oublié ou une configuration trop permissive : voici comment un risque peut apparaître dans un service métier, et quelles protections examiner.
Exemples fictifs à visée pédagogique. Les vérifications décrites sont des critères à tester dans un périmètre autorisé, pas des résultats d’audit ni des incidents clients.
Comptes & authentification
01
Phishing : une fausse invitation à se connecter
Un collaborateur reçoit une invitation de partage imitant un outil habituel. Le lien mène vers une page qui cherche à récupérer ses identifiants.
Protection et vérification
Protection à envisager
Privilégier une authentification résistante au phishing, comme FIDO2/WebAuthn, et sécuriser la récupération du compte. Un code temporaire peut lui aussi être détourné.
Critère de vérification
Avec des comptes de démonstration, vérifier les méthodes imposées et les procédures de récupération, sans collecter de vrais identifiants.
Un portail accepte de nombreuses tentatives de connexion sur le même compte. Le risque augmente lorsque les mots de passe sont faibles.
Protection et vérification
Protection à envisager
Combiner limitation des tentatives, MFA et surveillance. Prévoir une récupération légitime : un verrouillage brutal peut être utilisé pour bloquer un utilisateur.
Critère de vérification
Sur un compte de test, un nombre borné d’échecs doit déclencher la protection convenue sans perturber les autres comptes.
Un mot de passe réutilisé sur plusieurs services expose le portail lorsqu’un autre service subit une fuite. Le password spraying vise plutôt de nombreux comptes avec quelques mots de passe courants.
Protection et vérification
Protection à envisager
Associer MFA et détection de comportements anormaux. Une limite fondée uniquement sur l’adresse IP ne couvre pas tous les usages distribués.
Critère de vérification
Employer uniquement des identifiants synthétiques et un volume limité ; vérifier les alertes et la prise en charge par l’équipe.
Une application utilise un cookie de session. Une page extérieure pourrait provoquer un changement d’adresse email si le serveur ne contrôle pas l’origine de l’action.
Protection et vérification
Protection à envisager
Activer la protection anti-CSRF du framework et vérifier les requêtes sensibles. SameSite complète cette défense ; le seul usage de POST ne suffit pas.
Critère de vérification
Une modification sans jeton valide doit être refusée, tandis que le formulaire légitime fonctionne. CSRF et XSRF désignent le même risque.
Un outil de support affiche les commentaires saisis par les utilisateurs. Un rendu non protégé peut transformer leur contenu en instructions pour le navigateur.
Protection et vérification
Protection à envisager
Encoder selon le contexte d’affichage ; assainir le HTML si ce format est nécessaire. La CSP est une défense complémentaire, pas un remplacement.
Critère de vérification
Avec des marqueurs inoffensifs en environnement isolé, vérifier que le texte reste du texte et que le formatage autorisé fonctionne.
Un utilisateur connecté demande une facture par son identifiant. Si l’API ne vérifie pas le propriétaire et l’organisation, elle peut retourner un document qui ne lui appartient pas.
Protection et vérification
Protection à envisager
Contrôler côté serveur l’autorisation sur chaque ressource. Un identifiant difficile à deviner ne remplace pas cette règle.
Critère de vérification
Deux utilisateurs et deux organisations fictives permettent de vérifier les accès autorisés et refusés. Notre laboratoire .NET illustre ce principe.
Une fonction importe une image depuis une URL fournie par l’utilisateur. Sans restriction, le serveur pourrait contacter des ressources qui ne sont pas destinées au public.
Protection et vérification
Protection à envisager
Restreindre les destinations, protocoles et sorties réseau. Traiter explicitement les redirections et la résolution des noms.
Critère de vérification
Utiliser des services simulés : les destinations exclues doivent rester inaccessibles, y compris après une redirection. Aucun service tiers n’est sollicité.
Fichiers joints : un document accessible sans autorisation
Un espace client accepte des justificatifs. Un fichier mal contrôlé ou stocké publiquement peut exposer des données ou introduire un contenu dangereux.
Protection et vérification
Protection à envisager
Limiter types et tailles, contrôler le contenu, isoler le stockage et vérifier les droits au téléchargement. Le nom du fichier ne prouve pas son type.
Critère de vérification
Avec des fichiers inoffensifs, vérifier le refus des formats exclus et l’impossibilité de lire le document d’un autre compte.
Un pipeline affiche une configuration complète pendant un déploiement. Une clé peut alors devenir accessible aux personnes qui consultent les journaux.
Protection et vérification
Protection à envisager
Révoquer ou renouveler le secret exposé selon la procédure convenue ; corriger la journalisation et limiter les accès. Supprimer une ligne ne suffit pas.
Critère de vérification
Employer un marqueur fictif pour vérifier l’absence de valeur sensible dans les sorties et contrôler les permissions du pipeline.
Un service chargé de lire un fichier dispose de droits sur un ensemble de ressources. Une compromission aurait alors un impact plus large que son usage normal.
Protection et vérification
Protection à envisager
Réduire les actions et le périmètre des rôles, en tenant compte des droits hérités. Distinguer l’administration des ressources et l’accès à leurs données.
Critère de vérification
Dans un environnement dédié, vérifier que la tâche nécessaire fonctionne et que les opérations exclues sont refusées.
Un contrôle SCA signale une bibliothèque vulnérable. L’équipe doit déterminer la version concernée, son usage et les possibilités de mise à jour.
Protection et vérification
Protection à envisager
Consulter l’avis de sécurité, mettre à jour vers une version corrigée et vérifier la compatibilité. Documenter une exception plutôt que masquer une alerte.
Critère de vérification
Relancer l’analyse et les tests applicatifs. Distinguer une correction vérifiée d’un risque temporairement accepté.
Une fiche aide à poser la bonne question ; elle ne remplace pas l’étude de votre architecture. Pour chaque contrôle retenu, nous définissons les prérequis, la preuve attendue et les conditions d’arrêt avec votre équipe.
Cadrer le test
Choisir les composants, comptes fictifs et environnements autorisés. Les tests de connexion sont limités en volume et ne visent jamais des utilisateurs réels sans accord explicite. Une simulation de phishing nécessite un cadre propre ; cette page ne lance aucune campagne.
Vérifier le refus et le fonctionnement normal
Le cas interdit doit être bloqué, mais le parcours légitime doit rester utilisable. Les preuves sont minimisées : comportement observé, extrait expurgé et version testée, sans mot de passe, jeton réel ou données client.
Corriger puis rejouer le contrôle
Conserver le scénario de non-régression et noter les points non vérifiés. La disparition d’une alerte ne suffit pas à établir une correction. Les références ci-dessus orientent la revue ; elles ne constituent pas une certification OWASP.
