Sécurité des applications web : la checklist 2026

Chaque année, l'OWASP Top 10 rappelle les mêmes familles de vulnérabilités, et chaque année des applications partent en production avec des failles critiques. En 2026, les attaques exploitent surtout les points d'intégration : API, dépendances et authentification. Cette checklist couvre les points essentiels à valider avant chaque mise en production, de l'injection à la gestion des secrets. Chaque ligne correspond à un scénario d'attaque documenté : les appliquer ne rend pas une application invulnérable, mais réduit drastiquement la surface exploitable.

1. Authentification et gestion des sessions

Les failles de contrôle d'accès restent la vulnérabilité la plus exploitée selon l'OWASP. Imposez le multifacteur, les passkeys FIDO2 et des sessions courtes avec rotation des jetons. Vérifiez que chaque endpoint valide l'autorisation, pas seulement l'authentification : un utilisateur connecté ne doit pas pouvoir accéder aux ressources d'un autre utilisateur (attaques IDOR).

• MFA obligatoire sur les comptes à privilèges et l'administration.
• Jetons JWT signés avec une clé forte, durée de vie courte et révocation côté serveur.
• Limitation de débit (rate limiting) sur les endpoints de connexion contre le brute-force.

2. Les injections : XSS, SQLi, SSRF

L'injection SQL se défend par les requêtes préparées et l'ORM. Le XSS par l'échappement systématique des sorties et une Content Security Policy stricte. Le SSRF, moins connu mais en forte hausse, consiste à faire appeler des serveurs internes via une URL fournie par l'utilisateur : validez les domaines autorisés et bloquez les adresses internes. Côté saisie, la validation côté serveur reste la règle : les contrôles JavaScript ne sont qu'un confort, jamais une protection.

« Une application web est aussi sûre que son point d'intégration le plus faible : chaque entrée est une porte d'entrée. »

3. Les dépendances et la supply chain

1. Scanner les dépendances en continu (npm audit, Renovate, Trivy, Dependabot).
2. Générer un SBOM (Software Bill of Materials) et le maintenir à jour à chaque version.
3. Vérifier les signatures des paquets et la provenance des images conteneur.
4. Supprimer les paquets inutilisés : chaque dépendance est une surface d'attaque.

4. En-têtes HTTP et durcissement

Quatre en-têtes font la différence : Content-Security-Policy (bloque l'exécution de scripts non autorisés), X-Content-Type-Options: nosniff, Referrer-Policy et Strict-Transport-Security. Côté cookies, activez Secure, HttpOnly et SameSite=Lax ou Strict pour neutraliser la plupart des attaques CSRF. X-Frame-Options ou frame-ancestors protège du clickjacking.

5. Secrets, chiffrement et monitoring

Plus aucun secret en clair dans le code, les variables d'environnement ou l'historique Git. Utilisez un coffre (Vault, AWS Secrets Manager, Doppler) avec rotation automatique. En production : TLS 1.2 minimum (TLS 1.3 idéal), HSTS, chiffrement des données au repos, et journalisation des accès avec alertes sur les événements anormaux — tentatives de connexion multiples, accès hors horaires, appels d'API suspects. Dans les pipelines CI/CD, ajoutez un portail de sécurité : échec du build si une vulnérabilité critique est détectée, signature des artefacts et vérification des images avant déploiement. Un déploiement automatisé sans contrôle de sécurité revient à automatiser la porte d'entrée de vos attaquants.