Comment réaliser un audit de sécurité pour le site web de votre petite entreprise

La plupart des sites web de petites entreprises ne sont pas compromis à cause d'une faille zero-day exotique. Ils se font pirater parce qu'un plugin obsolète est resté sans correctif pendant huit mois, parce qu'un mot de passe administrateur a été réutilisé depuis un compte de forum divulgué, ou parce qu'un formulaire a silencieusement accepté des données qu'il n'aurait jamais dû accepter. Un audit de sécurité est le moyen de repérer ces failles avant que quelqu'un d'autre ne le fasse. Ce guide vous accompagne pour en réaliser un vous-même, d'une manière suffisamment approfondie pour être utile mais réaliste pour une équipe sans service de sécurité dédié.

Ce qu'est réellement un audit de sécurité

Un audit de sécurité est un examen structuré de votre site web et de l'infrastructure qui l'entoure, destiné à identifier les faiblesses susceptibles d'entraîner une perte de données, une défiguration, une interruption de service ou un accès non autorisé. Ce n'est pas un simple scan. C'est un processus reproductible qui combine des outils automatisés, une inspection manuelle et une bonne dose de « qu'est-ce qu'un attaquant tenterait ici ».

Pour une petite entreprise, l'objectif n'est pas un durcissement de niveau militaire. Il s'agit de combler les failles bien connues et à forte probabilité qui représentent la grande majorité des incidents réels. Vous voulez passer de « on espère que tout va bien » à « nous avons vérifié, documenté et corrigé les problèmes évidents ».

Fixez les attentes dès le départ. Un bon premier audit fait généralement remonter un mélange de gains rapides (en-têtes manquants, mots de passe faibles) et de problèmes structurels (absence de sauvegardes, comptes administrateurs partagés) qui prennent plus de temps à résoudre. Les deux comptent.

Avant de commencer : périmètre et autorisation

Définissez ce que vous auditez. Un périmètre typique de petite entreprise comprend :

• Le site web public et tous les sous-domaines (blog, boutique, préproduction)
• Le CMS ou le framework ainsi que ses plugins, thèmes et dépendances
• L'environnement d'hébergement et la configuration du serveur
• Le DNS, l'authentification des e-mails et les certificats TLS
• Les accès administrateur : qui en dispose, comment ils se connectent et depuis où

Une règle à ne surtout pas ignorer : ne scannez et ne testez que les systèmes que vous possédez ou pour lesquels vous disposez d'une autorisation écrite. Lancer des scans agressifs contre un service tiers, un prestataire de paiement ou un hébergeur que vous ne contrôlez pas peut enfreindre leurs conditions d'utilisation et, dans certains cas, la loi. Gardez vos tests à l'intérieur de votre propre périmètre.

Par ailleurs, effectuez une sauvegarde complète avant de toucher à quoi que ce soit. Certaines vérifications peuvent déclencher les pare-feu applicatifs web, verrouiller des comptes ou solliciter brièvement le serveur. Vous voulez disposer d'un point de restauration propre.

Les couches à auditer

Raisonnez par couches. Chacune a ses propres modes de défaillance et ses propres outils.

1. Surface et configuration

Commencez par ce que l'internet peut voir. Vérifiez votre configuration TLS (validité du certificat, versions de protocole, robustesse des chiffrements) et confirmez que le HTTP redirige proprement vers le HTTPS. Passez en revue vos en-têtes de sécurité HTTP : Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options et Referrer-Policy sont ceux qui préviennent discrètement des classes entières d'attaques.

Recherchez aussi les fuites d'information. Les dossiers .git exposés, les fichiers .env lisibles publiquement, le listage de répertoire, les pages d'erreur verbeuses qui révèlent des traces d'appels et les panneaux d'administration par défaut situés à des URL prévisibles sont tous courants et faciles à corriger.

2. Application et code

C'est là que se cachent les bugs intéressants. Vous recherchez les grands classiques de l'OWASP : failles d'injection, contrôle d'accès défaillant, cross-site scripting, références directes non sécurisées à des objets et cross-site request forgery. Testez chaque entrée : champs de recherche, formulaires de contact, champs de connexion, paramètres d'URL et téléversements de fichiers.

Si vous développez des logiciels sur mesure, examinez attentivement l'authentification et la gestion des sessions. Les sessions sont-elles invalidées à la déconnexion ? Les réinitialisations de mot de passe sont-elles devinables ? Un utilisateur normal peut-il atteindre un point d'accès administrateur en modifiant l'URL ? Ces problèmes de logique métier apparaissent rarement dans les scans automatisés, ce qui explique précisément leur persistance.

Pour un regard plus poussé et offensif sur la manière dont ces failles s'enchaînent, notre guide sur le test d'intrusion détaille davantage l'état d'esprit et la méthodologie.

3. Dépendances et mises à jour

Les composants obsolètes sont la cause la plus fréquente à elle seule de compromission des petites entreprises. Inventoriez chaque plugin, bibliothèque, thème et paquet, puis confrontez chacun aux bases de données de vulnérabilités connues. Tout ce qui n'est pas maintenu ou pas corrigé est un risque. Si un plugin n'a pas été mis à jour depuis deux ans, considérez-le comme un risque, qu'une CVE ait déjà été publiée ou non.

4. Accès et identité

Auditez qui peut se connecter et comment. Recherchez les comptes partagés, les mots de passe faibles ou réutilisés, l'absence d'authentification multifacteur et les comptes dormants appartenant à des personnes parties. Les attaquants « piratent » rarement le système quand ils peuvent tout simplement se connecter avec des identifiants récoltés dans un e-mail de phishing. Cette couche humaine mérite sa propre attention, c'est pourquoi nous avons rédigé un article complémentaire sur la façon de protéger votre startup contre le phishing.

5. Infrastructure et reprise

Enfin, confirmez les bases ennuyeuses mais essentielles : des sauvegardes automatisées et testées (une sauvegarde que vous n'avez jamais restaurée n'est qu'une supposition), des règles de pare-feu et d'accès, une journalisation réellement conservée et un plan pour ce qui se passe si quelque chose tourne mal.

Catégories d'outils à utiliser

Vous n'avez pas besoin d'une suite coûteuse. Vous avez besoin d'un outil fiable dans chaque catégorie :

• Scanners TLS et d'en-têtes pour noter votre certificat et vos en-têtes de sécurité
• Scanners de vulnérabilités web pour automatiser la découverte des problèmes courants d'injection et de mauvaise configuration
• Scanners de dépendances et de CMS pour signaler les plugins obsolètes et les versions connues comme vulnérables
• Scanners de ports et de services pour voir ce qui est exposé sur votre serveur
• Vérifications de mots de passe et de secrets pour détecter les identifiants réutilisés et les clés codées en dur dans votre base de code

Les outils automatisés excellent en couverture et sont catastrophiques en jugement. Ils produisent des faux positifs et passent totalement à côté des failles de logique métier. Traitez leurs résultats comme une liste de pistes à vérifier à la main, pas comme un verdict.

Une véritable checklist d'audit

Parcourez-la dans l'ordre. Documentez chaque constat avec sa gravité et un responsable de la correction.

1. Effectuez une sauvegarde complète des fichiers et de la base de données, et confirmez que vous pouvez la restaurer.
2. Confirmez que le TLS est valide, moderne et imposé sur l'ensemble du site avec HSTS.
3. Vérifiez que les en-têtes de sécurité sont présents et correctement configurés.
4. Recherchez les fichiers sensibles exposés : .env, .git, sauvegardes, exports de configuration.
5. Inventoriez tous les plugins, thèmes et dépendances, puis corrigez ou supprimez tout ce qui est obsolète.
6. Testez chaque champ de saisie pour l'injection et le cross-site scripting.
7. Vérifiez le contrôle d'accès : tentez d'atteindre des URL d'administration et les enregistrements d'autres utilisateurs en tant qu'utilisateur à faibles privilèges.
8. Passez en revue tous les comptes utilisateurs, supprimez les comptes dormants et imposez la MFA sur chaque connexion administrateur.
9. Confirmez des mots de passe forts et uniques et vérifiez les identifiants par rapport aux listes de fuites connues.
10. Scannez les ports ouverts et désactivez les services dont vous n'avez pas besoin.
11. Vérifiez que la journalisation est activée, conservée et inclut les événements de connexion et d'erreur.
12. Testez que les sauvegardes automatisées s'exécutent et se restaurent correctement.
13. Rédigez les constats, attribuez des responsables et fixez une date de nouvel audit.

Transformer les constats en corrections

Un audit qui se termine par un document ne change rien. Priorisez selon le risque réel : un problème exploitable par un visiteur anonyme l'emporte sur un problème théorique qui exige un accès administrateur. Corrigez immédiatement les éléments à forte gravité et faible effort, planifiez le travail structurel et consignez explicitement les risques acceptés pour que rien ne soit oublié.

Ensuite, faites-en une habitude. Relancez la checklist chaque trimestre, et toujours après un changement majeur : un nouveau plugin, une refonte, une migration ou une nouvelle intégration. La sécurité est un état que vous maintenez, pas une tâche que vous accomplissez une fois pour toutes.

Là où un partenaire vous aide

Certains constats sont simples à corriger en une après-midi. D'autres (la réécriture d'une authentification défaillante, un pipeline de déploiement durci ou une surveillance continue) tirent profit de mains expérimentées. Si votre audit a fait remonter des problèmes que vous n'êtes pas équipé pour résoudre, ou si vous préférez qu'un spécialiste prenne en charge l'ensemble du processus, l'équipe d'Innovation T peut vous aider. Découvrez nos services ou contactez-nous et nous vous aiderons à transformer une checklist en un site web véritablement plus sécurisé.