Un site web peut sembler fonctionner sans incident tout en laissant des portes ouvertes : comptes trop puissants, logiciels non corrigés ou données accessibles par erreur. Un audit de sécurité permet de repérer ces faiblesses avant qu’elles ne deviennent une panne, une fuite ou une intrusion.
La méthode repose sur un périmètre clair, des vérifications adaptées et un plan de correction suivi dans le temps. Pour garder un fil concret, prenons l’exemple d’une PME fictive qui souhaite examiner son site marchand et les services qui le font fonctionner.
À retenir : les priorités d’un audit de sécurité de site
- Périmètre défini et autorisations écrites avant les tests
- Contrôles techniques et organisationnels menés ensemble
- Failles classées selon leur impact et leur exposition
- Corrections attribuées à des responsables avec échéances
Définir le périmètre de l’audit de sécurité d’un site web
Avant toute analyse, l’équipe doit préciser ce qui sera examiné, car un test non autorisé peut perturber un service ou exposer des informations. Pour la PME fictive, le périmètre peut inclure le site public, son espace client, l’hébergement et les accès d’administration, sans toucher aux systèmes du prestataire de paiement.
Recenser les composants et les responsabilités
Cette première étape établit une carte des éléments concernés : noms de domaine, applications, serveurs, comptes, bases de données et services externes. Selon l’ANSSI, les guides d’hygiène informatique aident les organisations à structurer les mesures de protection ; ils ne remplacent toutefois pas l’examen propre à chaque infrastructure.
Le cahier des charges précise les tests autorisés, les horaires, les contacts d’urgence et les limites à respecter. Dans le cloud, il faut aussi clarifier la répartition des responsabilités entre l’entreprise et son fournisseur, afin de ne pas confondre leurs périmètres.
Éléments à cadrer avant les tests :
- Applications, environnements et adresses inclus dans la mission
- Comptes de test et niveaux d’accès disponibles
- Plages horaires et procédures d’arrêt en cas d’incident
- Contacts techniques et responsables de décision
| Élément | Question de cadrage | Exemple de preuve |
|---|---|---|
| Site web | Quelles pages et fonctions sont visées ? | Cartographie des parcours |
| Hébergement | Qui administre les serveurs ? | Contrat et inventaire technique |
| Comptes | Quels rôles seront testés ? | Comptes temporaires documentés |
| Services tiers | Quelles dépendances sont exclues ? | Liste des prestataires concernés |
Examiner les réglages et conduire l’analyse des vulnérabilités
Une fois le périmètre convenu, l’audit passe des documents aux contrôles concrets, en combinant vérifications manuelles et outils. Les résultats automatiques demandent toujours une validation : un scanner peut signaler une version vulnérable sans démontrer qu’elle est exploitable dans ce contexte.
Vérifier la configuration serveur et les protections du site
L’analyse examine les mises à jour, les services accessibles, les règles de pare-feu, les sauvegardes et les journaux. Elle vérifie aussi le certificat SSL, qui contribue à protéger les échanges entre le navigateur et le site, sans garantir à lui seul la sécurité de l’application ou des données stockées.
Selon l’OWASP, les risques des applications web comprennent notamment des erreurs de contrôle d’accès et des défauts de validation. L’auditeur vérifie donc si un utilisateur peut consulter les informations d’un autre compte, modifier des données sans autorisation ou contourner une étape prévue.
Vérifications techniques à documenter :
- Versions des logiciels et application des correctifs de sécurité
- Chiffrement des échanges et renouvellement du certificat SSL
- Configuration serveur, services exposés et règles réseau
- Contrôle des accès, rôles et procédures de récupération de compte
Un test d’intrusion peut compléter ces contrôles en simulant des scénarios convenus à l’avance. Il existe des approches avec peu d’informations initiales ou, au contraire, avec un compte de test et une documentation fournis ; le choix dépend des objectifs et des précautions formalisées.
Évaluer les risques et organiser les corrections
Les constats prennent leur sens lorsqu’ils sont rapprochés des usages et des conséquences possibles. Une faiblesse sur une page publique exposant des données personnelles ne se traite pas comme un défaut limité à un environnement de test isolé.
Classer les constats selon leur impact réel
Pour chaque faille, l’équipe décrit les conditions d’exploitation, les actifs touchés et les effets possibles sur la confidentialité, l’intégrité ou la disponibilité. Selon la CNIL, les organisations doivent protéger les données personnelles adaptées à leurs traitements ; l’audit doit donc examiner les accès, la conservation et les mesures de protection associées.
La PME peut, par exemple, découvrir qu’un ancien compte administrateur reste actif. Le constat devient prioritaire si ce compte permet de modifier les commandes ou d’accéder aux informations des clients ; la correction consiste alors à désactiver le compte, revoir les droits et contrôler les journaux.
| Constat | Impact possible | Réponse à planifier |
|---|---|---|
| Compte inutilisé encore actif | Accès non autorisé à l’administration | Désactivation et revue des privilèges |
| Logiciel non corrigé | Exploitation d’une faille connue | Mise à jour après validation technique |
| Sauvegarde non testée | Restauration incertaine après incident | Essai de restauration documenté |
| Journalisation insuffisante | Enquête difficile après une anomalie | Collecte et conservation adaptées |
Ordre de traitement recommandé :
- Traiter d’abord les failles exploitables et fortement exposées
- Attribuer chaque correction à un responsable identifié
- Fixer une échéance cohérente avec le niveau de risque
- Vérifier le résultat après déploiement des changements
Rédiger un rapport d’audit utile aux équipes
Après l’analyse, le rapport d’audit doit permettre à la direction de décider et aux équipes techniques d’agir. Il distingue les constats vérifiés des recommandations, explique les limites des tests et évite de noyer les lecteurs dans des alertes sans contexte.
Relier chaque constat à une action vérifiable
Un document exploitable décrit la faille, son emplacement, les conditions observées et les risques associés, puis propose une mesure corrective. Les preuves doivent être suffisantes pour permettre la vérification, sans inclure inutilement des données personnelles ou des secrets d’accès.
Contenu utile du rapport :
- Résumé des objectifs, du périmètre et des exclusions
- Constats classés avec preuves et niveau de priorité
- Recommandations techniques et organisationnelles
- Responsables, échéances et modalités de contrôle
Selon l’ANSSI, le recours à un prestataire qualifié selon le référentiel PASSI peut être pertinent pour certaines prestations d’audit. Le choix doit aussi tenir compte de l’expérience sur les technologies concernées, de la méthodologie et de la clarté des livrables.
Suivre la remédiation et maintenir la protection des données
Le rapport ne réduit pas le risque tant que les actions restent sans suivi. Une fois les corrections appliquées, l’équipe vérifie qu’elles répondent aux constats et qu’elles n’ont pas créé de nouveaux problèmes sur le site ou ses services associés.
Programmer les contrôles après les correctifs de sécurité
Le responsable suit les actions dans un registre partagé, avec leur état, leur échéance et une preuve de clôture. Après une modification importante de l’hébergement, des accès ou de l’application, un contrôle ciblé permet de vérifier que les protections tiennent dans la nouvelle configuration.
La fréquence dépend du risque, des changements et des obligations applicables ; une revue périodique ne dispense pas d’intervenir après un incident ou une évolution majeure. Pour la PME, le prochain contrôle peut commencer par les comptes privilégiés, les sauvegardes et les fonctions de commande, puis s’élargir selon les constats.