Comment auditer la sécurité de son site web sans y passer des jours

Dernièrement, un client m'appelle, paniqué : « Mon site a un cadenas vert, je suis tranquille, non ? » Je lui ai demandé combien de personnes avaient accès à son back-office WordPress. Silence. Puis : « Ah, on est six. Et l'ancienne stagiaire, je crois qu'on ne l'a jamais retirée. »

Voilà. Le cadenas vert ne dit rien de ça. Le HTTPS, c'est le minimum syndical, un certificat à 0 € que n'importe quel hébergeur installe en trois clics. Il chiffre le transport, un point c'est tout. Il ne vous dit rien sur les comptes orphelins, les plugins abandonnés depuis deux ans, ou cette sauvegarde qui n'a jamais été testée. Auditer la sécurité de son site web, ce n'est pas vérifier qu'on a un cadenas. C'est aller voir ce qui se passe derrière la porte.

Dans cet article, je vous donne la méthode que j'applique réellement, avec les priorités, les outils, et les erreurs que j'ai commises en la construisant.

Comment vérifier la sécurité d'un site web sans se perdre dans les outils

La première fois que j'ai lancé un scanner de vulnérabilités sur mon propre site, j'ai récupéré 47 alertes. J'ai mis une semaine à en triager une dizaine. Les 37 autres étaient des faux positifs ou des détails sans conséquence. J'ai perdu sept jours et j'ai appris la leçon la plus utile de ma vie de webmaster : un audit commence par un inventaire, pas par un scanner.

L'inventaire avant les outils

Avant de cliquer sur quoi que ce soit, notez noir sur blanc ce que vous possédez :

• Le nom de domaine et son registraire. Qui a les codes de transfert ?
• L'hébergeur, et si l'on est sur un mutualisé ou un VPS dédié (la surface d'attaque n'a rien à voir)
• La liste exhaustive des comptes ayant accès à l'administration, et leur date de dernière connexion
• Les extensions, plugins et thèmes installés, avec leur dernière mise à jour
• L'emplacement des sauvegardes, et surtout : la date du dernier test de restauration
• Le nom de qui a accès au certificat TLS et au DNS

Cette simple liste révèle souvent plus de risques que n'importe quel outil payant. Sur un site e-commerce que j'ai repris, l'inventaire a fait remonter onze comptes administrateur pour une équipe de quatre personnes. Trois correspondaient à des prestataires partis depuis longtemps.

Les contrôles concrets à vérifier ensuite

Une fois l'inventaire fait, on passe aux vérifications techniques. Les points les plus rentables, dans l'ordre où je les traite :

1. En-têtes de sécurité HTTP (CSP, HSTS, X-Frame-Options, Referrer-Policy). Un rapporteur en ligne comme securityheaders.com donne une note en dix secondes. C'est gratuit et ça surligne les trous béants.
2. Gestion des sessions et cookies : attributs Secure, HttpOnly, SameSite correctement posés ? Durée de vie des sessions raisonnable ?
3. Contrôle des accès : double authentification active sur tous les comptes administrateur ? (Oui, tous. Pas seulement le vôtre.)
4. Extensions obsolètes : toute extension sans mise à jour depuis six mois est un risque. Je désinstalle sans état d'âme, et je le dis à mes clients sans détour.
5. Sauvegardes et journalisation : au moins une copie hors site, et une restauration testée dans l'année. Avez-vous des journaux d'accès conservés assez longtemps pour enquêter en cas d'incident ?

Ce socle ne coûte rien en outils. Il demande deux à trois heures bien employées.

Comment faire l'audit d'un site web : la méthode en cinq étapes

Quand on me demande « comment faire l'audit d'un site web », je réponds souvent que 80 % du résultat se joue dans la préparation, pas dans l'exécution technique. Voilà l'enchaînement que j'applique.

1. Cadrer la cible et le périmètre

Quel site ? Quelle version ? Avec ou sans le back-office ? Les sous-domaines sont-ils inclus ? Le périmètre écrit noir sur blanc, c'est ce qui évite les mauvaises surprises à la livraison. Sur un projet, j'ai audité la boutique en ligne pendant que le sous-domaine staging restait ouvert avec des identifiants par défaut. Le rapport était bon, le site restait troué ailleurs.

2. Reconnaissance passive

Avant toute attaque, on collecte : technologies détectées, sous-domaines exposés, fichiers de configuration accessibles, adresses e-mail publiques. Des outils comme `Subfinder` ou `Amass` font ça sans rien casser. C'est la phase la moins risquée et souvent la plus instructive.

3. Analyse des vulnérabilités

Là entrent les scanners : OWASP ZAP, Burp Suite, Nmap. Mais attention, un scanner produit des résultats bruts. Le travail consiste à distinguer ce qui est réellement exploitable de ce qui ne l'est pas.

4. Rapport orienté risque métier

Un rapport qui liste 40 failles « critiques » sans hiérarchie est un rapport inutile. Ce que votre direction ou votre client veut savoir : qu'est-ce qui, s'il explose, coûte le plus cher en termes d'image, de données clients ou d'argent ? Classez par impact métier, pas par score technique.

5. Vérification des correctifs

Cette étape est presque toujours oubliée. On corrige, on croit que c'est bon, on ne vérifie pas. Sur un audit récent, deux correctifs sur cinq n'avaient pas été appliqués correctement, la faille était juste devenue plus discrète.

Quels sont les 4 critères de sécurité ?

Quatre critères classiques, issus du monde de la sécurité de l'information, suffisent à structurer n'importe quel audit web. Je les utilise comme grille de lecture pour ne rien oublier.

Critère	Question à se poser	Exemple de contrôle concret
Confidentialité	Qui peut lire ce qui ne devrait pas sortir ?	Permissions des dossiers serveur, cookies Secure, chiffrement au repos
Intégrité	Qui peut modifier les fichiers ou les données ?	Droits d'écriture limités, détection de modification (checksums), signatures d'upload
Disponibilité	Que se passe-t-il si on attaque massivement ou qu'on perd le serveur ?	Sauvegardes hors site, protection anti-DDoS, plan de reprise testé
Traçabilité	Pourra-t-on comprendre ce qui s'est passé ?	Journaux d'accès conservés, horodatage fiable, alerting sur connexions suspectes

Ce tableau paraît simpliste. Il est redoutable. La plupart des incidents que j'ai vus se logent dans une case qu'on avait déclarée « pas prioritaire ». La traçabilité, en particulier, est le parent pauvre : on la découvre à minuit, quand on cherche qui s'est connecté au back-office.

Quels sont les 3 types d'audits ?

La question revient souvent en début de mission, et la réponse dépend presque uniquement du niveau d'information qu'on vous autorise à avoir.

Audit en boîte noire

L'auditeur n'a aucune information préalable. Il attaque le site comme le ferait un inconnu, en partant de la page d'accueil. C'est le scénario le plus réaliste pour un attaquant, et le plus chronophage. Utile pour mesurer ce qu'un externe peut découvrir en quelques jours.

Audit en boîte grise

L'auditeur a un accès partiel : un compte utilisateur standard, la liste de l'architecture, parfois les sources côté client. C'est mon format préféré pour les PME. Il simule un utilisateur malveillant, ou un compte compromis, ce qui reste le scénario le plus fréquent.

Audit en boîte blanche

On ouvre tout : code source, base de données, configuration serveur. Le rendement est maximal, mais le réalisme diminue. C'est l'approche d'un audit de code, quand on veut être exhaustif avant une mise en production sensible.

Le choix dépend aussi de ce qu'on cherche à mesurer : le risque vu de l'extérieur (boîte noire), le scénario d'intrusion interne (boîte grise) ou la solidité du code (boîte blanche). Les trois peuvent se combiner, mais rarement dans le même budget.

Les questions qu'on me pose souvent, et mes réponses

Combien coûte un audit de sécurité web ?

Sur le marché français, un test d'intrusion sérieux sur un site vitrine commence autour de quelques milliers d'euros. Sur une application métier complexe, ça grimpe vite. Les scans automatisés gratuits existent, mais ils ne remplacent pas un audit humain. Mon conseil : si votre budget est serré, investissez d'abord dans l'audit « boîte grise » — c'est le meilleur rapport entre scénario réaliste et coût maîtrisé.

Un audit est-il obligatoire ?

Il n'existe pas d'obligation générale d'audit de sécurité pour toutes les entreprises. En revanche, si vous traitez des données personnelles dans le cadre du RGPD, vous devez être capable de démontrer que vous avez mis en place des mesures de sécurité proportionnées. Un audit documenté est l'une des meilleures preuves. Pour les acteurs publics, le référentiel de l'ANSSI (via la démarche d'homologation) impose des contrôles précis.

Mon scanner signale 30 vulnérabilités, dois-je paniquer ?

Non. Une alerte n'est pas une faille exploitable. La première chose à faire est de qualifier chaque alerte : est-elle reproductible ? Exploitable sans authentification ? En contexte ? Sur les trente alertes, il y en a souvent trois ou quatre qui méritent une action immédiate.

À quelle fréquence refaire un audit ?

Au minimum une fois par an. Et à chaque changement majeur : nouvelle version du CMS, nouveau plugin sensible, migration d'hébergeur, ajout d'un moyen de paiement. J'ai vu des sites audités « conformes » dont la sécurité était devenue obsolète en six mois, simplement parce qu'une extension avait été mise à jour avec une régression.

Ce qui reste quand on a tout corrigé

Un audit ne vous promet pas l'invulnérabilité. Il vous dit où vous en êtes, à un instant donné, avec un périmètre donné. C'est un diagnostic, pas une garantie.

La vraie question n'est pas « suis-je sécurisé ? ». C'est « combien de temps mettrais-je à m'en apercevoir si quelque chose se passe ? ». Un site avec des journaux propres, une sauvegarde testée et une alerte sur les connexions inhabituelles vaut mieux qu'un site « audité » il y a trois ans dont personne ne sait plus ce qui a été corrigé. La sécurité d'un site web, c'est moins un état qu'une habitude.

Et si vous ne savez pas par où commencer, faites l'inventaire. Vous serez surpris de ce que vous trouverez. Moi, la première fois, je l'ai été.