Objectifs d’apprentissage
- comprendre les catégories OWASP Top 10:2025 ;
- différencier authentification, autorisation et gestion de session ;
- protéger secrets, données et dépendances ;
- concevoir validation, erreurs et logs de manière sûre ;
- intégrer la sécurité dans le cycle de développement ;
- raisonner en prévention, détection, réponse et récupération.
1. Penser en actifs, frontières et confiance
Commence par identifier ce que l’application doit protéger : comptes, données personnelles, commandes, fichiers, clés, fonctions d’administration. Ensuite, repère les frontières entre navigateur, API, base de données et services externes.
Chaque frontière doit poser une question : qui demande quoi, et pourquoi cette action est-elle autorisée ?
2. OWASP Top 10:2025
OWASP classe les risques Web critiques afin d’aider développeurs et équipes sécurité à prioriser leurs efforts. L’édition 2025 place notamment le contrôle d’accès cassé en tête.
| Catégorie | Idée défensive |
|---|---|
| A01 Broken Access Control | vérifier les permissions côté serveur pour chaque action sensible |
| A02 Security Misconfiguration | désactiver les valeurs par défaut inutiles, limiter l’exposition, configurer explicitement |
| A03 Software Supply Chain Failures | inventorier, mettre à jour et vérifier les dépendances et processus de build |
| A04 Cryptographic Failures | utiliser des mécanismes modernes et protéger les clés/secrets |
| A05 Injection | séparer données et instructions, valider les entrées, utiliser les API sûres du framework |
| A06 Insecure Design | penser aux scénarios d’abus avant l’implémentation |
| A07 Authentication Failures | protéger comptes, sessions, récupération et MFA |
| A08 Software or Data Integrity Failures | vérifier provenance, signatures et chaîne de déploiement |
| A09 Security Logging & Alerting Failures | journaliser les événements utiles et détecter les anomalies |
| A10 Mishandling of Exceptional Conditions | prévoir les erreurs et défaillances sans divulguer d’informations sensibles |
3. Contrôle d’accès : ne jamais faire confiance au client
Masquer un bouton dans l’interface n’est pas une autorisation. Le serveur doit vérifier l’identité, le rôle et la propriété de la ressource avant chaque opération sensible.
- permissions minimales nécessaires ;
- contrôles centralisés plutôt que dispersés ;
- ressources filtrées selon l’utilisateur autorisé ;
- actions d’administration séparées des actions publiques.
4. Authentification, sessions et récupération
L’authentification prouve une identité ; l’autorisation détermine ses droits. Une bonne architecture traite aussi la session, l’expiration, la déconnexion et la récupération de compte.
- MFA pour les comptes sensibles lorsqu’elle est disponible ;
- secrets jamais codés en dur ;
- cookies de session configurés de manière appropriée ;
- limitation des tentatives et alertes sur comportements anormaux ;
- récupération de compte aussi robuste que la connexion principale.
5. Protéger les données et les secrets
HTTPS protège les données pendant le transport, mais il faut aussi limiter ce qui est collecté, protéger le stockage et éviter d’exposer les secrets au frontend.
Les mots de passe ne doivent pas être stockés en clair. Les applications doivent utiliser des mécanismes d’authentification et de hachage adaptés fournis par des bibliothèques reconnues plutôt que des algorithmes improvisés.
6. Entrées, sorties et injection
Une donnée venant d’un utilisateur, d’une URL, d’un fichier ou d’une API externe doit être considérée comme non fiable tant qu’elle n’a pas été validée selon le contexte.
- valider le type, la longueur et les valeurs attendues ;
- utiliser les requêtes paramétrées ou les abstractions sûres du framework ;
- encoder les sorties selon leur contexte d’affichage ;
- préférer
textContentlorsqu’on affiche du texte dans le navigateur ; - éviter de construire dynamiquement des instructions à partir de chaînes non fiables.
7. Chaîne logicielle et dépendances
Une application dépend souvent de centaines de paquets, images de conteneur, actions CI/CD ou services. OWASP 2025 met davantage l’accent sur les défaillances de chaîne logicielle.
- réduire le nombre de dépendances inutiles ;
- suivre les mises à jour et avis de sécurité ;
- verrouiller les versions avec les mécanismes de l’écosystème ;
- protéger les comptes et secrets du pipeline de déploiement ;
- examiner les nouvelles dépendances avant adoption.
8. Configuration sûre
Une application peut être vulnérable sans bug de code : mode debug actif, permissions trop larges, bucket public, headers absents, services inutiles ou comptes par défaut. La configuration doit être versionnée, revue et différente selon les environnements lorsque nécessaire.
9. Logs, alertes et réponse
Une défense efficace doit pouvoir répondre à la question : « que s’est-il passé ? ». Les logs doivent capturer les événements utiles sans enregistrer inutilement des secrets ou données sensibles.
- échecs répétés de connexion ;
- actions d’administration ;
- changements de permissions ;
- erreurs serveur anormales ;
- événements critiques du déploiement.
Un plan simple de réponse prévoit aussi qui est contacté, comment isoler le problème, comment restaurer le service et comment tirer les leçons de l’incident.
10. Intégrer la sécurité au développement
- Avant de coder : identifier actifs, utilisateurs et scénarios d’abus.
- Pendant : appliquer validation, autorisation, gestion des secrets et dépendances.
- Avant déploiement : revue de configuration, tests, sauvegardes et logs.
- Après : mises à jour, surveillance, réponse et amélioration continue.
Cette vision rejoint le NIST CSF 2.0 : Govern, Identify, Protect, Detect, Respond, Recover.
Évalue une phrase secrète
Le calcul reste local au navigateur. L’objectif est de visualiser l’effet de la longueur et de la diversité, pas d’évaluer un vrai secret de production.
Aucune donnée saisie.
Exercice — revue défensive d’un mini-site
Sur un projet que tu possèdes, crée une checklist sans tenter de contourner quoi que ce soit : secrets dans le dépôt, dépendances obsolètes, pages d’administration exposées, validation des formulaires, permissions serveur, HTTPS, logs et sauvegardes. Pour chaque point, note « conforme », « à vérifier » ou « à corriger ».
Concevoir des contrôles d’accès avant les fonctionnalités
Une application sécurisée ne repose pas sur le fait de cacher les boutons. Le serveur doit vérifier l’identité et les permissions pour chaque ressource sensible. Il faut distinguer authentification (qui est la personne ?) et autorisation (que peut-elle faire ?). La validation des données protège l’intégrité ; l’encodage de sortie limite les risques d’injection ; une bonne journalisation sert au diagnostic sans enregistrer de mots de passe.
Pratique pas à pas
- Dessine les rôles visiteur, élève et enseignant d’une application scolaire fictive.
- Crée une matrice : cours public, devoir personnel, modification des notes. Indique les opérations autorisées pour chaque rôle.
- Dans une application que tu possèdes, vérifie que chaque action sensible est autorisée côté serveur. N’effectue aucun test sur des comptes, réseaux ou services sans permission explicite.
Exemple à essayer
// Pseudo-code côté serveur : principe d'autorisation
function peutLireDevoir(session, devoir) {
if (!session?.userId) return false;
return session.role === 'enseignant' ||
devoir.eleveId === session.userId;
}
// Chaque requête doit demander l'autorisation,
// et pas seulement masquer un bouton dans le navigateur.Ce que tu dois observer : Le visiteur sans session n’est jamais autorisé, tandis qu’un élève ne peut accéder qu’à son propre devoir. En production, les droits doivent aussi être contrôlés pour les mutations et les ressources liées.
Erreur fréquente : Croire qu’un token valide donne accès à toutes les données ou que les seules restrictions dans JavaScript côté client constituent une protection suffisante.
Vérifie que tu as compris
Quelle est la différence entre authentification et autorisation ?
L’authentification identifie l’utilisateur ; l’autorisation décide quelles actions il peut réaliser.
Pourquoi éviter d’enregistrer des mots de passe dans les logs ?
Parce qu’un journal peut être consulté, transféré ou conservé ; un secret enregistré devient une nouvelle surface de risque.
Une fois l’atelier réalisé et les questions comprises, valide cette étape dans ton parcours.
À retenir
- La sécurité commence par la conception et le contrôle d’accès.
- Le serveur doit vérifier les droits, même si l’interface semble bloquer l’action.
- Les dépendances et le pipeline font partie de la surface de risque.
- Les erreurs, logs, sauvegardes et plans de réponse comptent autant que la prévention.
- Les tests restent limités aux environnements autorisés.
Teste ta compréhension
Quel cadre convient à un audit de sécurité ?