Aller au contenu principal

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.

Publié le
7 min de lecture

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.

Découvrez les accompagnements WebAiLab en lien avec le sujet de cet article.

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