Parent : [[INDEX-IA]]

Sécurité — Vecteurs oubliés : supply chain, SSRF, IAM, JWT, secrets, logs

❌ Supply chain — la chaîne de dépendances ignorée

Problème : Sécuriser son propre code en ignorant ses dépendances laisse un vecteur d'attaque massif et invisible ouvert.

Solution : Auditer régulièrement les dépendances directes ET transitives. Utiliser npm audit, pip-audit, trivy en CI. Épingler les versions exactes (lockfile committé). Surveiller les packages avec accès réseau ou filesystem dans leur install script.

Exemple : event-stream (npm, 2018) — package légitime racheté, backdoor injectée dans une dépendance transitive de milliers de projets. Le code "sécurisé" du projet était intact.

❌ SSRF — le vecteur oublié dans les architectures cloud

Problème : Permettre à une application de faire des requêtes HTTP vers des URLs fournies par l'utilisateur expose l'infrastructure interne.

Solution : Toute URL externe fournie par un utilisateur doit être validée contre une whitelist stricte AVANT la requête. Bloquer les plages RFC1918 (10.x, 172.16-31.x, 192.168.x), localhost, et surtout 169.254.169.254 (metadata AWS/GCP/Azure).

Exemple : curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ depuis une instance EC2 compromise via SSRF → credentials AWS live avec les permissions du rôle de la machine.

❌ Permissions IAM/RBAC trop larges en prod

Problème : Donner * ou des permissions admin à un service applicatif crée une surface d'attaque catastrophique si le service est compromis.

Solution : Principe du moindre privilège service par service. Chaque service reçoit exactement les permissions dont il a besoin. Auditer avec IAM Access Analyzer (AWS) ou équivalent. Les permissions inutilisées depuis 90 jours doivent être retirées.

Exemple : Lambda qui envoie des emails avec iam:* → compromission du Lambda = compromission de tout le compte.

❌ Secrets dans les variables d'environnement — fausse sécurité

Problème : Les env vars sont accessibles à tout process sur la machine, dans les logs de crash, et dans les images Docker buildées.

Solution : Les secrets doivent être dans un vault (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) injectés au runtime. Jamais dans les env vars de build, jamais dans les Dockerfiles, jamais dans les docker-compose.yml commités.

Exemple : docker history myimage révèle les ENV mis pendant le build. docker inspect container révèle toutes les env vars d'un container live.

❌ JWT — valider uniquement la signature sans vérifier les claims

Problème : Un token correctement signé avec un claim exp dépassé ou un aud incorrect est accepté comme valide par du code qui ne vérifie que la signature.

Solution : Valider systématiquement : signature + exp + iat + aud + iss. Ne pas accepter l'algorithme none — certaines librairies l'acceptent par défaut.

Exemple : {"alg":"none"} dans le header JWT — des librairies populaires acceptaient ce token sans signature comme valide jusqu'en 2015.

❌ Logs sans masquage — la fuite de données par les traces

Problème : Les logs de prod contiennent fréquemment des PII, tokens, passwords en clair car personne n'a audité ce qui est loggué.

Solution : Auditer les logs de prod avec une regex sur les patterns sensibles. Implémenter un middleware de sanitisation. Ne jamais logger un objet request complet sans masquage.

Exemple : logger.info("Request body:", req.body) avec {"password":"...", "credit_card":"..."} → tout est dans les logs, accessible à tous les devs avec accès au log aggregator.

❌ Exposed .git en prod

Problème : Un dossier .git accessible publiquement expose l'historique complet du code source, les secrets committé, les branches de feature.

Solution : Vérifier curl -s https://monsite.com/.git/config. Si ça retourne un fichier, le repo est exposé. Configurer le webserver pour bloquer l'accès à tous les dotfiles.

Exemple : git-dumper https://target.com/.git ./recovered — reconstruit l'intégralité du repo source depuis un .git exposé en quelques secondes.

❌ Pas de rate limiting sur les endpoints sensibles

Problème : Un endpoint d'auth ou de reset password sans rate limiting est trivial à bruteforcer ou à utiliser pour de l'énumération de comptes.

Solution : Rate limiting par IP + par compte sur : login, reset password, verify OTP, resend OTP, search by email/phone. Message d'erreur identique pour "compte inexistant" et "mauvais password". Lockout progressif avec backoff exponentiel.

Exemple : /api/check-email sans rate limit → script qui teste 10M d'emails en quelques heures pour construire une liste de comptes revendable.

Pattern — Comment un attaquant priorise ses cibles

Problème : Défendre l'infrastructure en pensant comme un défenseur rate la logique attaquante réelle.

Solution : Un attaquant priorise : (1) accès faciles non patchés, (2) credentials dans des repos publics ou logs, (3) services exposés sans auth. Il ne force pas la porte blindée — il cherche la fenêtre ouverte. Auditer l'inventaire des "fenêtres ouvertes".

Exemple : Recherche Shodan product:"Kibana" — des milliers de dashboards ELK sans auth exposant des logs de prod avec tokens et PII. Effort attaquant : 0.

Pattern — Ce qu'un audit rate systématiquement : la logique métier

Problème : Les audits automatisés détectent les vulnérabilités techniques connues mais ratent les failles de logique applicative.

Solution : Tester les flux métier avec des cas limites : quantité négative, prix modifié dans le body, réutilisation d'un token de reset. Ces bugs ne sont pas dans les CVE — ils sont dans la compréhension du domaine.

Exemple : API e-commerce acceptant "quantity": -5 et créditant le compte au lieu de débiter. Aucun scanner automatique ne détecte ça.

Pattern — Défense en profondeur non cosmétique

Problème : Une infra sécurisée "en périmètre" s'effondre complètement si un seul point d'entrée est compromis.

Solution : Segmentation réseau stricte : chaque service ne peut parler qu'aux services dont il a besoin (zero trust). Logs d'accès centralisés avec alertes sur les anomalies. Rotation des credentials automatique.

Exemple : App server compromise → ne peut pas atteindre la DB (security group bloquant), ne peut pas accéder au vault (auth mutuelle TLS), ne peut pas appeler l'API interne (token scope limité).

❌ Headers de sécurité absents en prod

Problème : Les headers HTTP de sécurité sont absents sur la majorité des apps en prod car aucune erreur fonctionnelle ne les signale manquants.

Solution : Checklist minimale : Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Strict-Transport-Security, Referrer-Policy. Tester avec securityheaders.com.

Exemple : Sans X-Frame-Options, n'importe qui peut iframer votre app bancaire et superposer des boutons transparents (clickjacking).