Audit de sécurité d’un site web : la checklist pour PME
Checklist d’audit de sécurité d’un site web de PME : mises à jour, extensions, comptes admin, HTTPS, en-têtes HTTP, formulaires et sauvegardes à vérifier.
Pour faire un premier contrôle de sécurité de votre site, vérifiez sept zones : les mises à jour du système et des extensions, les comptes administrateurs, le HTTPS, les en-têtes HTTP, les formulaires, les sauvegardes testées et les accès des prestataires. Cette checklist ne remplace pas un audit professionnel, mais elle repère les faiblesses les plus courantes sans outil spécialisé, et elle prépare utilement un audit approfondi.
Elle s’adresse aux dirigeants et responsables de site de TPE et PME. Les points techniques sont expliqués simplement, avec ce qu’il faut demander à son prestataire quand on ne peut pas les vérifier soi-même.
Pourquoi faire un contrôle de sécurité de son site ?
Un site est une porte d’entrée : il héberge des formulaires, parfois des comptes clients, et il représente votre image. Les recommandations nationales de Cybermalveillance.gouv.fr pour sécuriser son site internet rappellent que sa sécurisation passe par des gestes de base : mises à jour, mots de passe robustes, sauvegardes, protection de l’accès à l’administration.
Contrôler régulièrement est moins coûteux que réparer après incident. Si vous constatez une compromission, passez directement à notre guide site WordPress piraté : que faire.
Les mises à jour et les extensions sont-elles à jour ?
Les failles les plus exploitées sont souvent des failles connues, déjà corrigées par l’éditeur, mais non appliquées sur le site.
- Le système (WordPress ou autre CMS, framework) est à la version supportée la plus récente.
- Les extensions et thèmes sont à jour, et tous sont encore maintenus par leur auteur.
- Les extensions inutilisées sont supprimées, pas seulement désactivées.
- Aucune extension ou thème n’a été installé depuis une source non officielle.
- La version de PHP ou du moteur d’exécution est encore prise en charge par son éditeur.
Un site dont les composants sont abandonnés ne peut plus être sécurisé durablement. Dans ce cas, une refonte peut être plus raisonnable que des correctifs répétés.
Les comptes d’administration sont-ils protégés ?
- Chaque personne a son propre compte nommé ; pas de compte partagé.
- Les comptes des anciens prestataires et salariés sont supprimés.
- Les mots de passe sont longs, uniques, stockés dans un gestionnaire de mots de passe.
- Une double authentification est activée pour l’accès à l’administration. Voir la double authentification en entreprise.
- Le nom d’utilisateur « admin » par défaut n’est pas utilisé.
- Le nombre de comptes ayant les droits d’administrateur est réduit au nécessaire.
Le HTTPS est-il correctement configuré ?
HTTPS chiffre les échanges entre le visiteur et le site. Contrôlez que :
- toutes les pages s’ouvrent en HTTPS, et l’adresse en HTTP redirige vers HTTPS ;
- le certificat n’est pas expiré et son renouvellement est automatique ou suivi ;
- aucune page n’affiche d’alerte de contenu mixte (images ou scripts appelés en HTTP) ;
- le domaine, y compris les sous-domaines, est couvert.
HTTPS protège le trajet des données ; il ne dit rien du code du site ni de la qualité de sa sécurité.
Les en-têtes de sécurité HTTP sont-ils en place ?
Les en-têtes HTTP sont des instructions envoyées par le serveur au navigateur. La documentation de l’OWASP sur les en-têtes de sécurité HTTP recense ceux à connaître. Voici les principaux :
| En-tête | Rôle |
|---|---|
| Strict-Transport-Security | Force le navigateur à utiliser HTTPS pour ce site |
| Content-Security-Policy | Limite les sources de scripts et de ressources autorisées, ce qui réduit les risques d’injection de scripts |
| X-Content-Type-Options | Empêche le navigateur de deviner le type d’un fichier |
| Referrer-Policy | Contrôle les informations d’origine transmises à d’autres sites |
| Permissions-Policy | Restreint l’accès à certaines fonctions du navigateur (caméra, localisation) |
| Protection contre l’intégration dans un cadre (X-Frame-Options ou directive frame-ancestors) | Évite qu’une page soit affichée dans un cadre trompeur |
Pour vérifier, ouvrez les outils de développement de votre navigateur, onglet Réseau, et examinez les en-têtes de la réponse de la page d’accueil. Un en-tête absent n’est pas forcément une faille grave, mais son absence est un signe de configuration à revoir. Une politique CSP trop stricte peut casser des fonctions : testez-la avant de la généraliser.
Les formulaires et les entrées utilisateur sont-ils sûrs ?
- Les formulaires de contact limitent les envois abusifs (limitation de débit, dispositif anti-robot).
- Les champs sont validés côté serveur, pas seulement dans le navigateur.
- Les fichiers téléversés sont limités en type et en taille, et ne sont pas exécutables.
- Les messages d’erreur n’affichent pas de détails techniques (chemins, versions, requêtes).
- Les données personnelles collectées sont limitées au nécessaire, et la mention d’information figure près du formulaire. Voir mentions légales, RGPD et cookies.
- L’adresse de réception des messages est surveillée et reçoit bien les envois.
Les sauvegardes sont-elles complètes et testées ?
Une sauvegarde n’a de valeur que si elle se restaure. Vérifiez que fichiers et base de données sont couverts, qu’une copie est conservée hors de l’hébergement principal, que plusieurs dates sont disponibles et qu’une restauration a été essayée récemment. Notre article sur la maintenance et les sauvegardes détaille la méthode et le contenu d’une revue de maintenance.
Qui a accès à quoi, côté hébergement et domaine ?
- Le nom de domaine est à votre nom, avec une adresse de contact que vous contrôlez.
- Les accès à l’hébergeur, au registrar, à la messagerie et aux outils de statistiques sont listés avec un responsable.
- Les accès FTP/SFTP, bases de données et clés d’API inutiles sont supprimés.
- Les prestataires disposent de droits limités à leur mission.
- Les journaux d’accès sont conservés assez longtemps pour reconstituer un incident.
Quand faire appel à un professionnel ?
Cette checklist traite le niveau de base. Appelez un professionnel si votre site gère des paiements ou des comptes clients, si vous avez eu un incident, si un client vous demande des garanties, ou si vous ne pouvez pas vérifier plusieurs points. Notre audit de sécurité du site web reprend ces contrôles de façon structurée, avec un rapport priorisé. Et pour savoir si un test d’attaque simulée est plus adapté, lisez pentest ou audit de sécurité : que choisir ?. Pour les failles web les plus courantes, lisez l’OWASP Top 10 expliqué aux dirigeants ; côté équipe, la sensibilisation à l’hameçonnage traite l’autre porte d’entrée fréquente.
Questions fréquentes sur le contrôle de sécurité
À quelle fréquence contrôler son site ?
Il n’y a pas de rythme imposé. Un contrôle des mises à jour et des comptes est raisonnable à chaque évolution du site, et une revue plus complète une à deux fois par an convient à beaucoup de sites vitrines. Un site avec comptes clients ou paiement mérite un suivi plus resserré, à définir avec votre prestataire.
Un outil en ligne qui « note » mon site suffit-il ?
Ces outils donnent des indices utiles, comme la présence d’en-têtes ou la validité du certificat, mais ils ne voient ni les droits d’accès, ni la qualité du code, ni les sauvegardes. Considérez-les comme un premier regard. N’y soumettez que votre propre site.
Que faire si je découvre un point préoccupant ?
Notez-le avec la date, ne tentez pas d’en « profiter » pour tester plus loin, et transmettez le constat à la personne qui administre le site. Changez les mots de passe concernés si un compte peut être exposé. Si vous soupçonnez une compromission, suivez les étapes de l’article site piraté : que faire.
Cette checklist s’applique-t-elle à un site non WordPress ?
Oui pour l’essentiel : mises à jour des composants, comptes, HTTPS, en-têtes, formulaires, sauvegardes et accès sont communs à tous les sites. Seul le vocabulaire change (extensions, bibliothèques, modules).
Pour obtenir un état des lieux de votre site, écrivez-nous en décrivant votre site et ses outils, sans nous transmettre de mot de passe. Notre page maintenance et sécurité présente le suivi dans la durée.
Comprendre les notions de ce guide
Retrouvez les définitions, exemples et limites de ces concepts dans notre lexique IA.
Pour mettre ces idées en pratique
Découvrez les accompagnements WebAiLab en lien avec le sujet de cet article.
- Faire contrôler la sécurité de votre site
Vérifier mises à jour, extensions, en-têtes HTTP, accès et sauvegardes, avec un rapport priorisé.
- Situer l’audit dans une démarche de cybersécurité
Choisir par où commencer entre diagnostic, audit, test d’intrusion et sensibilisation.
Partagez cet article
Aidez vos collègues à découvrir ce contenu
Parlons de votre projet
Décrivez-nous votre besoin : nous vous répondons sous 24 h, sans engagement.
Articles similaires
Continuez votre lecture avec ces articles connexes
OWASP Top 10 expliqué simplement aux dirigeants de PME
OWASP Top 10 expliqué sans jargon : les dix catégories de failles web de l’édition 2025, leur sens pour un site de PME et les questions à poser au prestataire.
Pentest ou audit de sécurité : lequel choisir pour votre site ?
Pentest ou audit de sécurité : objectifs, méthodes et livrables comparés, avec des repères simples pour choisir selon votre site, vos données et votre budget.
Site WordPress piraté : que faire, dans quel ordre ?
Site WordPress piraté : les premiers gestes, du blocage des accès au nettoyage, avec sauvegardes, mots de passe, notification CNIL sous 72 h et prévention.