Pièges classiques et OWASP Top 10

Qu’est-ce que l’OWASP Top 10 ?

L’OWASP (Open Worldwide Application Security Project) publie régulièrement une liste des 10 catégories de vulnérabilités les plus critiques dans les applications web. C’est la référence du secteur pour prioriser la sécurité applicative.

Les 10 catégories (édition 2021)

Zoom sur les pièges les plus courants

Injection (A03)

L’application insère des données utilisateur dans une commande ou une requête sans les assainir. L’attaquant en profite pour modifier la commande elle-même.

SQL Injection : la plus connue. L’attaquant modifie une requête SQL pour accéder à des données ou contourner l’authentification.

Saisir ' OR '1'='1 dans un champ login peut retourner tous les utilisateurs si la requête n’est pas protégée.

XSS (Cross-Site Scripting) : injection de code JavaScript dans une page vue par d’autres utilisateurs. Permet de voler des cookies de session, de rediriger vers une fausse page, etc.

Comment s’en protéger :

• Ne jamais concaténer des données utilisateur dans une requête ou du HTML
• Utiliser des requêtes préparées (SQL) et l’échappement automatique (templates)
• Valider et rejeter les entrées inattendues côté serveur

Broken Access Control (A01)

Déjà couvert dans le module précédent — c’est la première cause de vulnérabilité en 2021.

Les formes les plus fréquentes : BOLA (accès aux ressources d’un autre utilisateur) et absence de vérification de rôle sur des endpoints sensibles.

Security Misconfiguration (A05)

Les failles ne viennent pas toujours du code — souvent de la configuration.

Exemples fréquents :

• Pages d’erreur qui exposent la stack trace (chemin de fichiers, version du framework, requête SQL)
• Comptes ou mots de passe par défaut non changés (admin/admin)
• Headers de sécurité HTTP absents (Content-Security-Policy, X-Frame-Options…)
• Fonctionnalités de debug activées en production

Vulnerable Components (A06)

Utiliser une dépendance (librairie, framework, image Docker) qui contient une faille connue et non corrigée.

En 2021, la faille Log4Shell dans la librairie Java Log4j a touché des millions d’applications. Le simple fait d’avoir la dépendance en place suffisait à être vulnérable.

Comment s’en protéger :

• Maintenir les dépendances à jour
• Utiliser des outils d’audit automatique (npm audit, Dependabot, Snyk…)
• Supprimer les dépendances inutilisées

SSRF — Server-Side Request Forgery (A10)

L’attaquant pousse le serveur à effectuer une requête vers une ressource qu’il ne devrait pas atteindre : réseau interne, service cloud, métadonnées de l’instance.

Exemple : une fonctionnalité “prévisualiser une URL” qui accepte n’importe quelle URL. L’attaquant saisit l’adresse du service de métadonnées AWS pour récupérer les credentials de l’instance.

Comment s’en protéger :

• Valider et filtrer strictement les URLs acceptées en entrée
• Bloquer les requêtes vers les adresses internes (169.254.x.x, 10.x.x.x…)

Cryptographic Failures (A02)

Données sensibles transmises ou stockées sans protection adéquate.

Exemples :

• Mots de passe stockés en clair ou hachés avec MD5/SHA1
• Données sensibles transmises en HTTP (non chiffré)
• Clés de chiffrement codées en dur dans le code source

Logging & Monitoring Failures (A09)

Sans logs, impossible de détecter une intrusion, de comprendre ce qui s’est passé, ni d’alerter en temps réel.

Ce qu’il faut journaliser :

• Les tentatives de connexion échouées
• Les accès refusés (403)
• Les actions sensibles (suppression, export, changement de rôle)

Ce qu’il ne faut jamais mettre dans les logs :

• Mots de passe, tokens, numéros de carte
• Données personnelles non nécessaires au diagnostic

En résumé : les réflexes à avoir