Un après-midi, je reçois un mail d'un client : « On a reçu une alerte de Google, notre site est signalé comme dangereux. Tu peux regarder ? » Le type tient une boutique en ligne, 40 commandes par jour, et son hébergeur vient de suspendre le compte pour cause de script malveillant. Il ne savait pas qu'il avait un problème. Il l'a appris par un écran rouge.
Voilà pourquoi j'ai fini par considérer l'audit de sécurité comme une hygiène de base, pas comme un luxe réservé aux banques. Un site non audité n'est pas un site sûr : c'est un site dont on ignore encore les failles. Et dans mon expérience, ce n'est presque jamais l'attaque sophistiquée qui fait tomber une PME. C'est un plugin abandonné depuis deux ans, ou un dossier de sauvegarde laissé en accès libre.
Je vais vous montrer comment auditer la sécurité d'un site web concrètement, ce que vous pouvez faire vous-même en une soirée, et surtout comment interpréter ce que les outils vous crachent — parce que c'est là que tout le monde se plante.
Points clés à retenir
- Un audit utile commence par la cartographie de ce qui est exposé, pas par le lancement d'un scanner.
- Un scanner qui remonte 200 alertes ne vous dit rien tant que vous ne savez pas trier le bruit du risque réel.
- Trois signaux imposent de passer à un audit professionnel : données personnelles, paiement en ligne, API ouverte.
- Les correctifs les moins glamour (mises à jour, sauvegardes testées, droits d'accès) éliminent la majorité des incidents.
Comment auditer la sécurité de son site web : par où commencer sans se noyer
Première erreur que j'ai commise, et que je vois commettre à chaque fois : installer un scanner, cliquer sur « Scan », et attendre la liste magique. Mauvaise entrée en matière. Un scanner ne connaît pas votre site. Il ne sait pas que /backup-2023 contient la base clients en clair, ni que votre formulaire de contact accepte n'importe quoi.
Cartographier la surface exposée avant de scanner quoi que ce soit
Prenez une feuille. Listez ce que votre site donne à voir à un inconnu :
- les domaines et sous-domaines actifs (le classique staging.monsite.fr oublié, sans mot de passe)
- les formulaires qui envoient des données quelque part
- l'espace d'administration, et qui peut y accéder
- les accès techniques : FTP, SSH, panneau d'hébergement
- tout service tiers branché dessus (paiement, newsletter, chat, analytics)
Sur un site que j'ai repris il y a deux ans, cette simple liste a révélé un sous-domaine de test resté en ligne, protégé par un couple identifiant/mot de passe digne d'un tutoriel de 2010 — admin/admin. Pas de scanner, pas de faille exotique : une porte ouverte avec un panneau « entrez ».
Ce que vous pouvez vérifier vous-même, sans être expert
Une bonne partie de l'audit tient dans des contrôles manuels, et honnêtement, ils attrapent plus de choses que bien des outils automatiques.
- Le certificat HTTPS : valide, à jour, et surtout redirection systématique du HTTP vers le HTTPS.
- Les en-têtes de sécurité HTTP : au minimum une politique de sécurité du contenu et une protection contre le détournement de clic.
- Les enregistrements DNS liés au mail (authentification de l'expéditeur) : sans eux, n'importe qui peut envoyer des mails en usurpant votre domaine.
- Les versions affichées : un CMS qui annonce son numéro de version en pied de page offre un mode d'emploi à l'attaquant.
- Les comptes utilisateurs : qui a encore un accès alors qu'il est parti de l'entreprise depuis huit mois ?
Ces cinq points, je les vérifie sur chaque site que je touche. Ils prennent une heure. Ils ne coûtent rien.
Les outils d'audit ne valent que par la façon dont vous lisez leurs résultats
Bon, parlons des outils. Ils sont utiles. Mais le piège, c'est de croire que la sortie d'un scanner est un diagnostic. C'est un symptôme. À vous de faire le travail d'interprétation.
Comment éviter le piège du scanner qui sort 200 alertes
La première fois que j'ai lancé un scanner sur mon propre site, j'ai eu 187 alertes. J'ai paniqué. Puis j'ai regardé : une bonne moitié concernait des bibliothèques JavaScript chargées depuis un CDN et signalées comme « obsolètes » alors qu'elles étaient à jour. Une autre partie pointait des en-têtes manquants sans aucun impact réel sur mon usage.
La règle que j'applique maintenant : trier par exploitabilité, pas par sévérité affichée. Trois questions à poser devant chaque alerte :
- Est-ce qu'un attaquant peut réellement l'atteindre depuis l'extérieur ?
- Qu'est-ce qu'il gagne s'il l'exploite ? (rien, un peu de bruit, ou vos données ?)
- Est-ce reproductible, ou est-ce un artefact de l'outil ?
Un en-tête manquant sur une page statique qui ne traite aucune donnée, c'est du bruit. Le même en-tête manquant sur votre page de connexion, c'est autre chose. Le contexte décide, pas la couleur du badge.
Audit manuel, scan automatique, test d'intrusion : quelle différence ?
| Approche | Ce qu'elle détecte | Ce qu'elle rate | Quand y recourir |
|---|---|---|---|
| Contrôles manuels | Configurations oubliées, accès trop larges, fichiers exposés | Failles applicatives subtiles | Toujours, en premier |
| Scanner automatique | Versions obsolètes, en-têtes absents, ports ouverts | Logique métier, enchaînements d'attaques | En routine, pour la veille |
| Test d'intrusion | Exploitation réelle, chemins d'attaque combinés | Rien de magique, mais coûteux | Site critique, données sensibles |
Mon avis, et je l'assume : pour 80 % des sites vitrines et blogs, un audit manuel sérieux suivi d'un scanner en veille suffit. Le test d'intrusion payant, sur un site qui n'a ni compte utilisateur ni paiement, c'est payer pour un rapport que personne ne lira.
Quand un auto-audit ne suffit plus : les trois signaux qui doivent vous alerter
Il y a un moment où bricoler devient irresponsable. Pas par principe, mais parce que le coût d'une erreur dépasse largement le prix d'un audit externe. Trois signaux, dans mon expérience :
Données personnelles, paiement, API exposée
Si votre site stocke des données personnelles (noms, adresses, mails de clients), traite des paiements, ou expose une API accessible depuis l'extérieur, vous n'êtes plus dans le registre du site vitrine. Vous êtes dans celui où une faille se traduit par une obligation de notification, des clients mécontents, et parfois une sanction. À ce stade, faire appel à quelqu'un dont c'est le métier n'est pas un luxe, c'est de la prudence élémentaire.
J'ai vu un développeur freelance découvrir, lors d'un audit externe, que son formulaire d'inscription permettait de créer un compte administrateur par simple modification d'un champ caché. Trois semaines de travail, une ligne de code. Il ne l'aurait jamais vu seul, parce qu'on ne teste pas ce qu'on a écrit avec les mêmes yeux.
Le volet juridique que personne ne regarde
Un audit de sécurité, ce n'est pas que de la technique. Qui a accès à quoi ? Y a-t-il une procédure en cas d'incident ? Les sauvegardes sont-elles testées, ou juste supposées fonctionner ? La partie organisationnelle est celle qu'on saute tous, et c'est souvent celle qui fait la différence le jour où ça casse.
Un exemple concret : une entreprise que j'accompagnais faisait des sauvegardes quotidiennes. Impeccable sur le papier. Sauf que personne n'avait jamais essayé de restaurer. Le jour où un ransomware a chiffré le serveur, on a découvert que les archives étaient corrompues depuis des mois. Une sauvegarde non testée n'existe pas.
Un plan d'action concret pour une première passe
Si vous ne devez retenir qu'une chose de cet article, c'est celle-ci : commencez par le basique. Pas par la faille exotique, par l'évident.
- Mettre à jour le CMS, les plugins, les thèmes — et supprimer ceux qui ne servent plus
- Activer l'authentification à deux facteurs sur tous les accès administrateur
- Vérifier que les sauvegardes existent et qu'on sait les restaurer
- Fermer les dossiers de test et vider les fichiers de sauvegarde laissés en ligne
- Limiter les droits : personne n'a besoin d'un accès administrateur pour rédiger un article
- Mettre en place une surveillance qui vous prévient quand quelque chose change
Faites ça, et vous aurez éliminé la majorité des incidents que je vois passer dans une année. Le reste, c'est de l'optimisation.
Le vrai enseignement de mes propres ratés, c'est que la sécurité n'est pas un état qu'on atteint une fois pour toutes. C'est un réflexe qui s'entretient. Le site que vous avez audité en janvier n'est plus le même site en juin : un plugin a bougé, un accès a été oublié, une bibliothèque a pris l'eau.
Alors la question n'est pas « mon site est-il sécurisé ? ». Elle est : « quand ai-je regardé pour la dernière fois ? » Si la réponse vous fait hésiter, vous avez votre point de départ.
