Sécurité Application Web Entreprise : Checklist 2025

• Les 10 vulnérabilités web les plus critiques (OWASP)
• Authentification et gestion des accès : bonnes pratiques
• Chiffrement des données : en transit et au repos
• Conformité RGPD et sécurité applicative

La sécurité application web entreprise représente aujourd’hui un enjeu critique pour toute organisation qui déploie des outils numériques métiers. Une faille exploitée peut compromettre des données clients, bloquer l’activité pendant plusieurs jours, et exposer l’entreprise à des sanctions réglementaires. Pourtant, la majorité des vulnérabilités exploitées sont connues depuis des années et documentées dans des référentiels publics.

Cette checklist 2025 s’appuie sur le classement OWASP Top 10 et propose des tests de validation concrets pour chaque vulnérabilité. L’objectif : transformer une liste de risques abstraits en actions vérifiables par vos équipes techniques, que vous développiez une application web sur mesure ou que vous auditiez une solution existante.

Les 10 vulnérabilités web les plus critiques (OWASP)

Le projet OWASP (Open Web Application Security Project) publie tous les trois ans un classement des risques de sécurité les plus fréquents et les plus graves dans les applications web. Le Top 10 2021 reste la référence en 2025 pour structurer un audit de sécurité.

Injection SQL : l’attaquant insère du code SQL malveillant dans un champ de formulaire pour extraire, modifier ou supprimer des données. Exemple réel : un champ de recherche qui accepte ' OR '1'='1 sans validation peut exposer l’intégralité d’une table utilisateurs. Test de validation : tous les paramètres utilisateurs doivent passer par des requêtes préparées (prepared statements) avec liaison de paramètres. Aucune concaténation de chaînes dans les requêtes SQL.

Cross-Site Scripting (XSS) : l’attaquant injecte du JavaScript dans une page vue par d’autres utilisateurs, permettant le vol de cookies de session ou la redirection vers un site malveillant. Exemple : un champ commentaire qui affiche <script>alert(document.cookie)</script> sans échappement. Test : tout contenu généré par l’utilisateur doit être échappé avant affichage (HTML entities) ou filtré via une Content Security Policy stricte.

Cross-Site Request Forgery (CSRF) : l’attaquant force un utilisateur authentifié à exécuter une action non intentionnelle (virement bancaire, changement de mot de passe). Test : chaque formulaire ou requête sensible doit inclure un token CSRF unique, régénéré à chaque session et validé côté serveur.

Broken Access Control : un utilisateur accède à des ressources pour lesquelles il n’a pas d’autorisation (consultation de factures d’autres clients via manipulation d’URL). Test : chaque endpoint doit vérifier les permissions côté serveur, jamais uniquement côté client. Un utilisateur lambda ne doit jamais pouvoir accéder à /admin/users même en tapant l’URL directement.

Security Misconfiguration : serveurs non patchés, messages d’erreur verbeux exposant la structure de la base de données, comptes par défaut non modifiés. Test : désactiver les messages d’erreur détaillés en production, supprimer tous les comptes par défaut, maintenir les dépendances à jour via un scanner automatisé (Dependabot, Snyk).

Vulnerable and Outdated Components : utilisation de bibliothèques avec des failles connues (Log4Shell, Heartbleed). Test : auditer les dépendances mensuellement avec npm audit, composer audit ou équivalent. Maintenir un inventaire des versions utilisées et un plan de mise à jour.

Identification and Authentication Failures : mots de passe faibles acceptés, absence de limitation des tentatives de connexion, tokens de session prévisibles. Test : imposer une politique de mot de passe forte (12 caractères minimum, complexité), implémenter un rate limiting sur les endpoints d’authentification (5 tentatives maximum par IP et par minute).

Software and Data Integrity Failures : déploiement de code non vérifié, absence de signature des mises à jour. Test : utiliser des pipelines CI/CD avec validation de signature, vérifier l’intégrité des dépendances via checksums (package-lock.json, composer.lock).

Security Logging and Monitoring Failures : absence de logs d’événements critiques (connexions échouées, modifications de privilèges), détection d’intrusion inexistante. Test : logger toutes les actions sensibles avec horodatage et identifiant utilisateur, configurer des alertes automatiques sur les patterns suspects (100 tentatives de connexion en 1 minute).

Server-Side Request Forgery (SSRF) : l’application effectue des requêtes vers des ressources internes non exposées publiquement à la demande de l’attaquant. Test : valider et filtrer strictement toutes les URL fournies par l’utilisateur, interdire les requêtes vers des plages d’IP privées (127.0.0.1, 10.0.0.0/8, 192.168.0.0/16).

Authentification et gestion des accès : bonnes pratiques

L’authentification constitue la première ligne de défense d’une application web. Une implémentation défaillante expose l’ensemble du système, quelle que soit la robustesse des autres couches de sécurité.

OAuth 2.0 et OpenID Connect : pour les applications B2B ou SaaS, déléguer l’authentification à un fournisseur d’identité externe (Okta, Auth0, Azure AD) réduit la surface d’attaque. L’application ne stocke jamais de mots de passe, seulement des tokens d’accès à durée de vie limitée. Implémentation : utiliser une bibliothèque OAuth certifiée (Passport.js, Spring Security OAuth), jamais une implémentation maison.

JSON Web Tokens (JWT) : pour les API stateless, les JWT permettent de transporter des informations d’identité signées. Règle critique : toujours valider la signature côté serveur, définir une expiration courte (15 minutes pour les access tokens, 7 jours maximum pour les refresh tokens), stocker les refresh tokens en base avec possibilité de révocation.

Authentification multi-facteurs (MFA) : l’activation du MFA réduit de 99,9 % le risque de compromission de compte selon Microsoft. Implémentation minimale : TOTP (Time-based One-Time Password) via Google Authenticator ou Authy. Pour les applications critiques : ajouter des clés de sécurité matérielles (YubiKey) compatibles FIDO2.

Gestion des rôles et permissions (RBAC) : définir des rôles granulaires (admin, éditeur, lecteur) avec permissions explicites par ressource. Règle d’or : privilège minimum par défaut. Un nouvel utilisateur ne doit avoir accès qu’aux ressources strictement nécessaires à sa fonction. Documenter la matrice de permissions dans le cahier charges application web dès la phase de conception.

Rotation des secrets : les clés API, tokens de service et certificats doivent être renouvelés régulièrement. Un token compromis doit pouvoir être révoqué en moins de 5 minutes. Utiliser un gestionnaire de secrets centralisé (HashiCorp Vault, AWS Secrets Manager) plutôt que des variables d’environnement en dur.

Chiffrement des données : en transit et au repos

Le chiffrement protège les données même en cas de compromission d’une couche de sécurité. Deux périmètres distincts nécessitent des approches différentes.

Chiffrement en transit (TLS/SSL) : toutes les communications entre client et serveur doivent utiliser HTTPS avec TLS 1.3 minimum. TLS 1.0 et 1.1 sont obsolètes et vulnérables (attaques POODLE, BEAST). Configuration serveur : désactiver les cipher suites faibles, activer HTTP Strict Transport Security (HSTS) pour forcer HTTPS sur tous les sous-domaines. Test : vérifier la configuration via SSL Labs (score A minimum).

Chiffrement au repos : les données sensibles stockées en base (mots de passe, données bancaires, informations médicales) doivent être chiffrées. Pour les mots de passe : utiliser un algorithme de hachage adapté (bcrypt, Argon2) avec salt unique par utilisateur. Jamais MD5 ou SHA-1. Pour les autres données : chiffrement AES-256 avec gestion des clés externalisée.

Gestion des clés de chiffrement : la clé de chiffrement ne doit jamais être stockée au même endroit que les données chiffrées. Architecture recommandée : clés stockées dans un HSM (Hardware Security Module) ou un service cloud dédié (AWS KMS, Azure Key Vault), rotation automatique tous les 90 jours, journalisation de tous les accès aux clés.

Chiffrement des sauvegardes : une sauvegarde non chiffrée annule tous les efforts de sécurité. Les exports de base de données, les snapshots de machines virtuelles et les archives doivent être chiffrés avant stockage. Tester la procédure de restauration tous les trimestres pour valider que les clés de déchiffrement sont accessibles.

Le cout developpement application web d’une application sécurisée intègre ces mécanismes dès la conception. Un chiffrement ajouté après coup coûte trois à cinq fois plus cher et introduit souvent des régressions fonctionnelles.

Conformité RGPD et sécurité applicative

Le Règlement Général sur la Protection des Données impose des obligations de sécurité technique dès la conception de l’application. La conformité RGPD n’est pas un exercice juridique déconnecté de la sécurité — c’est une exigence technique concrète.

Privacy by design : les mesures de protection des données doivent être intégrées dès la phase de conception, pas ajoutées après coup. Concrètement : minimiser la collecte de données (ne demander que ce qui est strictement nécessaire), pseudonymiser les identifiants dans les logs, chiffrer par défaut les données sensibles. Une application web sur mesure conforme RGPD documente ces choix dans son architecture technique.

Gestion du consentement : pour toute collecte de données personnelles, l’utilisateur doit donner un consentement explicite, libre et éclairé. Implémentation : bannière de cookies conforme (refus aussi simple que l’acceptation), formulaires avec cases à cocher non pré-cochées, possibilité de retirer le consentement à tout moment. Stocker la preuve du consentement (date, heure, version de la politique de confidentialité acceptée).

Droit à l’oubli et portabilité : l’application doit permettre l’export de toutes les données d’un utilisateur (format structuré, machine-readable) et leur suppression complète sur demande. Test : un utilisateur qui demande la suppression de son compte doit voir toutes ses données personnelles effacées dans un délai de 30 jours, y compris dans les sauvegardes (ou les sauvegardes doivent être chiffrées avec une clé révocable par utilisateur).

Notification des violations : en cas de fuite de données, l’entreprise dispose de 72 heures pour notifier l’autorité de contrôle (CNIL en France, CNDP au Maroc). Préparation technique : mettre en place une procédure de détection des violations (monitoring des accès anormaux), documenter la chaîne de responsabilité, tester le plan de réponse aux incidents une fois par an.

La maintenance application web mesure inclut des audits de conformité réguliers et la mise à jour des mécanismes de protection en fonction de l’évolution du cadre réglementaire. Une application conforme en 2025 ne le sera pas nécessairement en 2026 sans maintenance active.

La sécurité d’une application web entreprise repose sur une approche systématique : identification des vulnérabilités via des référentiels reconnus (OWASP), implémentation de contrôles techniques vérifiables (authentification forte, chiffrement), et conformité réglementaire intégrée dès la conception. Cette checklist fournit les points de contrôle minimaux pour toute application manipulant des données métiers ou clients. Un audit annuel par un tiers indépendant valide la robustesse de l’implémentation et identifie les nouveaux vecteurs d’attaque avant qu’ils ne soient exploités.