OWASP Top 10 (Open Web Application Security Project)

L’OWASP Top 10 est un document de référence qui identifie les dix menaces de sécurité les plus critiques pour les applications web. C’est un point de départ essentiel pour toute stratégie de sécurité.

Vulnérabilité	Description	Exemple d’Attaque	Prévention (Bonne Pratique)
1. Injection	Envoyer des données non fiables à un interpréteur (SQL, NoSQL, OS Command).	SQL Injection : `SELECT * FROM users WHERE user='admin' OR 1=1--'`	Utiliser des requêtes préparées (Prepared Statements) ou des ORM. Valider et échapper toutes les entrées utilisateur.
2. Liens Brisés & Contrôle d’Accès Déficient	L’application ne restreint pas correctement l’accès aux fonctions ou données sensibles.	Un utilisateur normal accède à la page d’administration via une URL directe.	Implémenter des contrôles d’accès côté serveur à chaque point d’accès. Ne jamais faire confiance au client.
3. Stockage de Données Sensibles	Les données sensibles (mots de passe, numéros de carte) ne sont pas correctement protégées.	Mots de passe stockés en clair ou hachés faiblement.	Chiffrer toutes les données sensibles au repos et en transit. Utiliser des fonctions de hachage fortes (bcrypt, Argon2) pour les mots de passe.
4. Entités Externes XML (XXE)	Un parseur XML vulnérable traite des références à des entités externes non fiables.	Un attaquant lit des fichiers système ou exécute du code à distance via XML.	Désactiver le traitement des entités externes dans les parseurs XML.
5. Erreur de Configuration Sécurisée	Configuration par défaut non sécurisée, fichiers inutilisés, messages d’erreur détaillés.	Un attaquant trouve des fichiers de sauvegarde ou des répertoires d’administration non protégés.	Appliquer une stratégie de Hardening (durcissement) : désactiver les fonctionnalités inutiles, supprimer les exemples, restreindre les accès aux fichiers.
6. Cross-Site Scripting (XSS)	Injection de scripts côté client (JavaScript) malveillants dans une page web vue par d’autres utilisateurs.	Un attaquant injecte un script qui vole les cookies de session.	Échapper toutes les données affichées côté client. Utiliser des frameworks qui protègent nativement contre le XSS (React, Vue).
7. Désérialisation Dangereuse	Désérialisation d’objets non fiables, pouvant entraîner l’exécution de code à distance.	Un attaquant injecte un objet malveillant qui exécute une commande système.	Éviter la désérialisation de sources non fiables. Utiliser des formats de données sécurisés (JSON simple).
8. Composants Vulnérables	Utilisation de bibliothèques, frameworks ou autres composants avec des vulnérabilités connues.	Une bibliothèque tierce avec une faille de sécurité permet une exécution de code à distance.	Mettre à jour régulièrement les dépendances. Utiliser des outils d’analyse de vulnérabilités (OWASP Dependency-Check).
9. Log & Monitoring Insuffisants	Absence de journaux d’événements (logs) ou de supervision adéquate des attaques.	Une attaque réussie n’est pas détectée avant des mois.	Implémenter une journalisation centralisée et des systèmes d’alerte pour les activités suspectes (tentatives de connexion échouées, erreurs API).
10. Falsification de Requête Côté Serveur (SSRF)	L’application ne valide pas l’URL fournie par l’utilisateur et effectue une requête vers une ressource interne ou externe inattendue.	Un attaquant force l’application à accéder à des serveurs internes ou à scanner des ports sur le réseau.	Valider toutes les URLs fournies par l’utilisateur. Utiliser une liste blanche d’hôtes autorisés.

Gestion des Secrets

Les “secrets” sont des informations sensibles (clés API, identifiants de base de données, certificats) qui ne doivent jamais être exposées publiquement ou stockées de manière non sécurisée. Bonnes Pratiques de Gestion des Secrets

Ne Jamais Commiter de Secrets :
- À Faire : Utiliser des variables d’environnement (process.env.DB_PASSWORD), des fichiers de configuration ignorés par Git (.env avec .gitignore).
- À Éviter : Mettre des identifiants et clés API directement dans le code source ou dans les fichiers de configuration sous contrôle de version.
Systèmes de Gestion de Secrets :
- Pour les environnements de production, utiliser des solutions dédiées comme HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, ou Google Secret Manager. Ces systèmes injectent les secrets de manière sécurisée au moment du déploiement ou de l’exécution.
Rotation des Secrets : Modifier régulièrement les clés et mots de passe pour minimiser les risques en cas de fuite.

Exemple de Code (Utilisation de Variables d’Environnement)

// Au lieu de: const DB_PASSWORD = "MySuperSecretPassword";

// Utiliser les variables d'environnement (Node.js)
const DB_PASSWORD = process.env.DB_PASSWORD; 

if (!DB_PASSWORD) {
  console.error("Erreur: Le mot de passe de la base de données n'est pas configuré.");
  process.exit(1); // Arrêter l'application
}

// Utilisation sécurisée du mot de passe
connectToDatabase(DB_PASSWORD);

Tests Automatisés (Sécurité Incluse)

Les tests automatisés ne sont pas seulement pour la fonctionnalité, ils sont une première ligne de défense contre les régressions de sécurité et les vulnérabilités introduites. Types de Tests Clés

Type de Test	Description	Impact Sécurité	Outils Courants
Unit Tests	Vérifient le comportement de petites unités de code (fonctions, méthodes).	Détectent les erreurs logiques qui pourraient mener à des vulnérabilités (ex: vérification d’autorisation incorrecte dans une fonction).	Jest, Vitest (JS), JUnit (Java), Pytest (Python)
Integration Tests	Vérifient l’interaction entre plusieurs unités de code (ex: service et base de données, deux microservices).	S’assurent que les contrôles d’accès et de validation fonctionnent correctement à travers les couches de l’application.	Similaires aux tests unitaires, mais avec des mocks et stubs moins agressifs.
End-to-End (E2E) Tests	Simulent le parcours d’un utilisateur réel à travers l’application entière.	Vérifient que les flux d’authentification/autorisation complexes fonctionnent comme prévu de bout en bout.	Cypress, Playwright (Web), Detox (React Native), Appium (Mobile)
Tests de Sécurité (DDoS, Pentest, SAST/DAST)	Tests spécialisés pour identifier des vulnérabilités de sécurité.	SAST (Static Analysis Security Testing) : Analyse le code source pour trouver des vulnérabilités connues (ex: injection SQL).	SonarQube, Snyk, Checkmarx
		DAST (Dynamic Analysis Security Testing) : Attaque l’application en cours d’exécution pour trouver des vulnérabilités (ex: XSS, injection).	OWASP ZAP, Burp Suite (manuels/automatisés)
		Tests de pénétration (Pentest) : Menés par des experts pour simuler des attaques réelles.	Outils manuels, expertise humaine.

Bonne Pratique (DevSecOps) Intégrer les outils de sécurité (SAST, DAST légers) directement dans le pipeline de CI/CD (intégration continue/déploiement continu) pour détecter les vulnérabilités le plus tôt possible dans le cycle de développement.

Architectures

Échanges de Données : APIs et Protocoles

Persistance : Bases de Données & Stockage

L'Art du Frontend : UI/UX, Performance et Accessibilité

Excellence Opérationnelle & Ticketing

Qualité & Bonnes Pratiques de Code

Green IT & Sobriété Numérique

Sécurité de votre code

OWASP Top 10 (Open Web Application Security Project)

Gestion des Secrets

Tests Automatisés (Sécurité Incluse)

​OWASP Top 10 (Open Web Application Security Project)

​Gestion des Secrets

​Tests Automatisés (Sécurité Incluse)

OWASP Top 10 (Open Web Application Security Project)

Gestion des Secrets

Tests Automatisés (Sécurité Incluse)