Sécurité applicative : les pratiques essentielles

Le Top 10 OWASP reste la référence pour comprendre les vulnérabilités les plus critiques des applications web. En 2023, les trois premières restent immuables : Broken Access Control, Cryptographic Failures et Injection. Ce ne sont pas des bugs exotiques — ce sont des erreurs de conception fondamentales que l'on retrouve dans des centaines d'applications en production aujourd'hui.

Les vulnérabilités OWASP les plus exploitées

• Broken Access Control — un utilisateur accède à des ressources ou des actions qui ne lui appartiennent pas. C'est la vulnérabilité n°1 : endpoints sans vérification de rôle, IDs prévisibles non vérifiés côté serveur (IDOR), escalade de privilèges silencieuse. La règle : deny by default, vérification systématique côté serveur, jamais côté client uniquement.

• Cryptographic Failures — exposition de données sensibles faute d'un chiffrement approprié. Mots de passe en clair ou hachés avec MD5/SHA1, données personnelles non chiffrées au repos, communication en HTTP plutôt qu'HTTPS, clés secrètes hardcodées dans le code source ou les variables d'environnement non protégées.

• Injection — SQL, LDAP, NoSQL, OS command injection. Chaque fois que des données non fiables sont interprétées comme des commandes plutôt que comme des données. Les requêtes préparées éliminent l'injection SQL. La validation stricte des inputs élimine les autres formes. L'IA générative aggrave ce risque : elle produit régulièrement des concaténations de chaînes là où des requêtes paramétrées s'imposent.

• Security Misconfiguration — headers HTTP manquants, comptes par défaut actifs, stack traces exposées en production, S3 buckets publics, ports ouverts inutilement. C'est la vulnérabilité la plus banale et souvent la plus rapide à exploiter.

• Vulnerable and Outdated Components — une dépendance avec une CVE critique non patchée est une porte ouverte. L'automatisation de la veille (Dependabot, Renovate, Snyk) est indispensable dans tout pipeline CI/CD sérieux.

Pratiques non négociables

• Authentification : tokens JWT à courte durée de vie (15 minutes), refresh token sécurisé en HttpOnly cookie, rotation des refresh tokens à chaque usage. Implémenter l'authentification à deux facteurs pour tous les accès sensibles.
• Mots de passe : hachage avec bcrypt (coût ≥ 12) ou argon2id — jamais MD5, SHA1 ou SHA256 seul. Vérification systématique via une bibliothèque dédiée, jamais une implémentation maison.
• SQL : requêtes préparées sans exception. Les ORM comme Hibernate protègent nativement, à condition de ne pas contourner avec du SQL natif non paramétré.
• Inputs : validation et assainissement côté serveur, pas seulement côté client. Whitelist plutôt que blacklist. Limiter la taille, le type et le format de chaque champ.
• Transport : HTTPS partout, HSTS activé avec max-age long et includeSubDomains, redirection automatique HTTP → HTTPS. Certificats renouvelés automatiquement (Let's Encrypt, ACM).
• Headers : Content Security Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy. Configurables en quelques lignes, ils neutralisent des classes entières d'attaques XSS et clickjacking.

Shift Left Security : intégrer la sécurité dans le cycle de développement

L'approche la plus efficace n'est pas de faire auditer l'application une fois par an — c'est d'intégrer la sécurité à chaque étape du développement.

Dans la CI/CD : les outils d'analyse statique (SAST) comme SonarQube, Semgrep ou Checkmarx détectent les patterns dangereux avant le merge. Les scanners de dépendances (OWASP Dependency-Check, Snyk) signalent les CVE critiques automatiquement. Les tests de sécurité dynamiques (DAST) comme OWASP ZAP peuvent être intégrés aux pipelines de staging.

Dans les revues de code : une checklist sécurité courte mais systématique — validation des inputs, gestion des autorisations, secrets dans le code, logs qui exposent des données sensibles — change significativement le niveau de sécurité moyen d'une équipe sans ralentir les livraisons.

Dans la formation : les développeurs qui comprennent pourquoi une injection SQL fonctionne ne font pas les mêmes erreurs que ceux qui ont juste appris à utiliser un ORM. Les labs interactifs (HackTheBox, OWASP WebGoat, TryHackMe) sont plus efficaces que les formations théoriques.

Un pentesting annuel par une équipe externe complète le dispositif — non pas comme filet de sécurité principal, mais comme validation indépendante. La sécurité parfaite n'existe pas : l'objectif est de rendre l'attaque suffisamment coûteuse pour que l'attaquant se tourne vers une cible plus facile.