Cas pratiques OWASP Top 10

Contexte : Vous reprenez une application web interne dont le module de connexion interroge directement une base de données relationnelle. Le Problème : Les développeurs ont construit la requête SQL en concaténant les entrées utilisateur, rendant l’application vulnérable à l’injection SQL. Code actuel : query = "SELECT * FROM users WHERE email = '" + email + "' AND password = '" + password + "'"; Contraintes : Vous ne pouvez pas modifier la structure de la base de données. La correction doit empêcher toute injection tout en conservant la logique métier existante. Livrable attendu : Proposer une version sécurisée utilisant des requêtes préparées ou un ORM empêchant l’injection SQL.

Contexte : Une API expose une route permettant de consulter les informations d’un utilisateur via son identifiant. Le Problème : Aucun contrôle ne vérifie que l’utilisateur connecté est autorisé à consulter la ressource demandée. Code actuel : app.get("/users/:id", (req, res) => { return db.users.findById(req.params.id); }); Contraintes : Implémenter une vérification d’autorisation basée sur l’identité de l’utilisateur authentifié. Livrable attendu : Proposer une correction garantissant que seul le propriétaire ou un administrateur peut accéder à la ressource.

Contexte : Une application stocke les mots de passe directement dans la base de données. Le Problème : En cas de fuite, tous les mots de passe seraient immédiatement exploitables. Code actuel : db.users.insert({ email: email, password: password }); Contraintes : Vous devez sécuriser le stockage sans casser le processus d’authentification. Livrable attendu : Proposer une solution basée sur un algorithme de hachage sécurisé (ex: bcrypt) et expliquer le processus de vérification.

Contexte : Une API publique autorise toutes les origines via une configuration CORS permissive. Le Problème : La configuration actuelle permet à n’importe quel domaine d’interagir avec l’API. Code actuel : app.use(cors({ origin: "*" })); Contraintes : Restreindre l’accès aux domaines autorisés sans bloquer les clients légitimes. Livrable attendu : Proposer une configuration CORS sécurisée limitant explicitement les origines autorisées.

Contexte : Un serveur web expose des informations détaillées dans les en-têtes HTTP. Le Problème : Les en-têtes révèlent la version exacte du serveur et des technologies utilisées. Contraintes : Corriger la configuration sans impacter la disponibilité du service. Livrable attendu : Proposer une configuration supprimant ou masquant les en-têtes sensibles et expliquant l’impact sécurité.

Contexte : Une application affiche des erreurs détaillées en cas d’exception. Le Problème : Les messages d’erreur révèlent des informations internes comme des chemins de fichiers et des requêtes SQL. Contraintes : Mettre en place un mécanisme centralisé de gestion d’erreurs. Livrable attendu : Proposer une stratégie masquant les détails techniques aux utilisateurs tout en conservant des logs détaillés côté serveur.

Contexte : Un formulaire permet aux utilisateurs de modifier leurs informations personnelles. Le Problème : Aucune protection CSRF n’est implémentée, exposant l’application à des requêtes forgées. Contraintes : Ajouter une protection sans modifier la logique métier principale. Livrable attendu : Décrire l’intégration d’un token CSRF unique par session et la vérification côté serveur.

Contexte : Une plateforme permet aux utilisateurs de publier des commentaires visibles publiquement. Le Problème : Les commentaires sont affichés sans échappement, permettant l’injection de scripts malveillants. Code actuel : <div class="comment">{{ userComment }}</div> Contraintes : Vous ne pouvez pas supprimer la fonctionnalité d’affichage dynamique. Vous devez sécuriser l’affichage côté serveur ou client. Livrable attendu : Proposer une solution d’échappement ou de sanitization empêchant toute exécution de script injecté.

Contexte : Une application permet l’upload de fichiers images pour les profils utilisateurs. Le Problème : Aucun contrôle strict du type de fichier n’est appliqué. Contraintes : Implémenter une validation côté serveur empêchant l’upload de scripts exécutables. Livrable attendu : Décrire une stratégie de validation basée sur le type MIME, l’extension et l’analyse du contenu.

Contexte : Une application web utilise des cookies pour maintenir la session utilisateur. Le Problème : Les cookies ne possèdent pas les attributs de sécurité nécessaires, exposant les sessions au vol via XSS ou interception réseau. Contraintes : Vous devez configurer les cookies sans modifier le système d’authentification existant. Livrable attendu : Décrire les paramètres de sécurité à activer (HttpOnly, Secure, SameSite) et expliquer leur rôle dans la protection des sessions.

Contexte : Une application utilise des bases de données pour stocker des informations sensibles, telles que des mots de passe et des informations bancaires. Le Problème : Les données sont stockées en texte clair et peuvent être exposées en cas de fuite ou d’accès non autorisé. Contraintes : Implémenter un chiffrement fort pour les données sensibles au repos dans la base de données et en transit sur le réseau. Livrable attendu : Proposer une stratégie de chiffrement pour les données sensibles en utilisant des technologies comme AES et TLS.

Contexte : Une API expose des informations sensibles sur les utilisateurs, mais il n’y a aucune validation sur les droits d’accès. Le Problème : Les utilisateurs non autorisés peuvent accéder aux données sensibles. Contraintes : Implémenter une gestion des rôles et des autorisations pour garantir que les utilisateurs n’accèdent qu’aux ressources pour lesquelles ils sont autorisés. Livrable attendu : Proposer une solution de contrôle d’accès avec gestion des rôles et des permissions au niveau de l’API.

Contexte : Une application permet aux utilisateurs de modifier leurs informations personnelles via des formulaires web. Le Problème : Il n’y a pas de mécanisme de protection contre les attaques CSRF, permettant à un attaquant d’envoyer des requêtes malveillantes au nom d’un utilisateur authentifié. Contraintes : Ajouter une protection CSRF sur tous les formulaires d'authentification et de modification de données sensibles. Livrable attendu : Fournir une solution de protection CSRF en utilisant des tokens de session pour garantir que les requêtes proviennent bien de l'utilisateur authentifié.

Contexte : Une application permet aux utilisateurs de soumettre des commentaires ou des messages dans des forums publics. Le Problème : Le formulaire n’applique aucune validation des entrées et permet l’injection de scripts malveillants dans la page. Contraintes : Implémenter une validation rigoureuse des entrées pour les rendre sûres avant l’affichage. Livrable attendu : Proposer une solution de validation ou de nettoyage des entrées pour prévenir les attaques XSS et garantir la sécurité des utilisateurs.

Contexte : Une application utilise des formulaires de connexion pour l’authentification des utilisateurs via une base de données MySQL. Le Problème : La requête de connexion permet des injections SQL qui peuvent compromettre la base de données. Contraintes : Sécuriser la requête sans affecter la logique métier de l’authentification. Livrable attendu : Proposer une solution utilisant des requêtes préparées ou un ORM pour éviter les injections SQL et améliorer la sécurité de l’authentification.

Contexte : Une application permet aux utilisateurs de télécharger des fichiers via un formulaire web. Le Problème : Les fichiers téléchargés ne sont pas validés correctement et des fichiers exécutables peuvent être envoyés. Contraintes : Implémenter un contrôle de type de fichier, d’extension et de taille sur les fichiers téléchargés. Livrable attendu : Proposer une solution de validation des fichiers côté serveur afin d'empêcher le téléchargement de fichiers malveillants.

Contexte : Un serveur web expose des informations sur les versions du logiciel et les configurations sensibles. Le Problème : Les informations révélées par les en-têtes HTTP et les messages d’erreur peuvent être utilisées par un attaquant pour cibler le serveur. Contraintes : Désactiver ou masquer les informations version dans les en-têtes HTTP et les messages d’erreur. Livrable attendu : Proposer une configuration durcie pour le serveur web afin de masquer les détails de la version et minimiser l’exposition.

Contexte : Une application web permet aux utilisateurs de rester connectés pendant une longue période sans renouveler leur session. Le Problème : La gestion des sessions n’est pas sécurisée, et les sessions peuvent être volées par des attaquants. Contraintes : Ajouter des mécanismes de sécurité comme les cookies sécurisés, l’expiration des sessions et le renouvellement des tokens d’authentification. Livrable attendu : Proposer une stratégie de gestion sécurisée des sessions utilisateurs, incluant l’utilisation de cookies HttpOnly et la mise en place de renouvellement automatique des sessions.

Contexte : Une application renvoie des erreurs détaillées aux utilisateurs, exposant des informations sensibles sur l’infrastructure. Le Problème : Les messages d’erreur révèlent des détails internes qui peuvent être exploités pour des attaques. Contraintes : Modifier la gestion des erreurs pour masquer les informations sensibles tout en consignant les erreurs à des fins d’analyse. Livrable attendu : Fournir une solution pour filtrer les messages d’erreur côté utilisateur tout en enregistrant les détails nécessaires pour le débogage sécurisé.

Contexte : Une application permet aux utilisateurs d’envoyer du contenu HTML comme commentaires. Le Problème : Le contenu envoyé n’est pas validé correctement, exposant l’application aux attaques XSS. Contraintes : Implémenter une validation stricte des entrées HTML et échappement des caractères dangereux. Livrable attendu : Fournir une solution de validation des entrées HTML côté client et serveur pour empêcher l’injection de scripts malveillants.

Contexte : Une entreprise utilise des services cloud pour stocker et traiter des informations sensibles telles que des numéros de carte bancaire. Le Problème : Les données sont stockées en clair dans les services cloud, exposant l’entreprise à des violations de données en cas d’attaque. Contraintes : Implémenter une stratégie de chiffrement des données au repos et en transit, en conformité avec les meilleures pratiques de sécurité cloud. Livrable attendu : Fournir une architecture de chiffrement hybride incluant le chiffrement côté client et côté serveur avec des clés de chiffrement gérées et renouvelées régulièrement.

Contexte : Une application utilise des bases de données pour stocker des informations sensibles comme des mots de passe et des numéros de carte bancaire. Le Problème : Les données sont stockées en texte clair ou avec un chiffrement obsolète. Contraintes : Implémenter un chiffrement fort pour les données sensibles à la fois au repos et en transit. Livrable attendu : Proposer une solution de chiffrement des données sensibles avec des algorithmes comme AES-256 et des clés de chiffrement rotatives.

Contexte : Une application web retourne des messages d’erreur détaillés qui incluent des informations internes comme des chemins de fichiers et des paramètres de base de données. Le Problème : Ces messages d’erreur exposent des informations sensibles qui peuvent être utilisées par des attaquants. Contraintes : Implémenter une gestion des erreurs qui masque les informations sensibles tout en enregistrant les erreurs pour l’audit interne. Livrable attendu : Fournir une solution de gestion des erreurs qui enregistre les exceptions sans révéler les détails sensibles aux utilisateurs.

Contexte : Une application e-commerce doit être capable de tracer toutes les actions des utilisateurs et des administrateurs dans le système. Le Problème : Aucune stratégie d’audit ou de journalisation n’est en place pour détecter les comportements anormaux ou malveillants. Contraintes : Implémenter un système centralisé d’audit qui consigne toutes les actions sensibles et génère des alertes sur les anomalies potentielles. Livrable attendu : Proposer une architecture de journalisation complète en utilisant des solutions comme ELK stack ou Splunk, avec des alertes en temps réel pour les comportements suspects.

Contexte : Une application de gestion de documents permet aux utilisateurs d’accéder à des documents confidentiels. Le Problème : Aucun contrôle d’accès granulaire basé sur les rôles et les attributs n’est appliqué. Contraintes : Implémenter un contrôle d’accès basé sur les attributs (ABAC) pour contrôler l’accès à des documents selon les rôles des utilisateurs et leurs attributs. Livrable attendu : Proposer une solution ABAC complète en implémentant un modèle de contrôle d’accès robuste et sécurisé pour les données sensibles.

Contexte : Une application e-commerce traite des transactions financières et interroge fréquemment la base de données pour récupérer des informations sensibles. Le Problème : Une mauvaise gestion des paramètres dans les requêtes permet à un attaquant d’injecter des commandes malveillantes. Contraintes : Sécuriser toutes les requêtes d’interaction avec la base de données sans impacter les performances. Livrable attendu : Proposer une solution robuste pour prévenir les injections SQL dans des requêtes complexes en utilisant des requêtes préparées, des ORM ou des procédures stockées.

Contexte : Une application web permet aux utilisateurs de modifier leurs informations personnelles via un formulaire. Le Problème : Aucune protection contre les attaques CSRF n’est mise en œuvre, permettant aux attaquants de soumettre des requêtes malveillantes au nom d’un utilisateur authentifié. Contraintes : Ajouter une protection CSRF sur tous les formulaires d'authentification et de modification de données sensibles. Livrable attendu : Fournir une solution de protection CSRF incluant la génération et la validation de tokens uniques pour chaque formulaire, empêchant les attaques de type CSRF.

Contexte : Une plateforme de réseaux sociaux permet aux utilisateurs de soumettre des liens et des contenus interactifs, mais n’applique aucune validation rigoureuse des entrées. Le Problème : Le formulaire n’applique aucune validation des entrées et permet l’injection de scripts malveillants dans la page. Contraintes : Mettre en place un filtrage et un assainissement des entrées à l’échelle de l’application, y compris les contenus utilisateurs et les interactions dynamiques. Livrable attendu : Fournir une architecture de validation et d’assainissement des entrées (input sanitization) et proposer une solution robuste pour la prévention de XSS, y compris l’utilisation de CSP (Content Security Policy).

Contexte : Des serveurs web et des services d’application sont déployés dans un environnement de production. Le Problème : Les configurations par défaut ne sont pas suffisamment sécurisées, exposant le serveur à des attaques potentielles. Contraintes : Réaliser un audit complet des configurations de sécurité des serveurs et des services pour désactiver les fonctionnalités inutiles et appliquer les bonnes pratiques de durcissement. Livrable attendu : Proposer une liste de configurations sécurisées et un guide détaillant les étapes pour durcir les serveurs et services contre les attaques.

Contexte : Une application web et une API exposent des données sensibles via des canaux de communication non sécurisés. Le Problème : Les données sensibles sont envoyées en clair sur le réseau, exposant les utilisateurs à des attaques de type man-in-the-middle. Contraintes : Implémenter des mécanismes de chiffrement forts pour assurer la confidentialité et l’intégrité des communications. Livrable attendu : Proposer une stratégie complète pour sécuriser les communications réseau en utilisant TLS/SSL, avec des clés publiques et privées robustes, et garantir la protection contre les attaques de type MITM.