Sécuriser un site web contre les attaques courantes : le guide essentiel

Un client m'appelle un mardi matin, paniqué. Son site e-commerce affiche une page blanche avec un message en anglais signé d'un groupe qu'il ne connaît pas. Il vend des cosmétiques bio, 40 commandes par jour, et là, plus rien. Deux heures plus tôt, tout fonctionnait. Je regarde les logs : une extension de formulaire de contact, abandonnée depuis dix-huit mois, avait une faille d'injection. Le pirate est entré par là, a posé un shell, et a commencé à chiffrer ses fichiers.

Sécuriser un site web contre les attaques courantes ne consiste pas à installer un plugin magique ni à cocher une case chez votre hébergeur. C'est un travail de fond, souvent ingrat, qui se joue sur des détails que personne ne voit tant que tout va bien. Et le jour où quelque chose casse, ces détails font toute la différence entre une journée de stress et une semaine de cauchemar.

Dans ce qui suit, je vais vous montrer ce qui marche vraiment, ce qui ne sert à rien, et par où commencer quand on a un budget limité et une journée chargée.

Par où commencer pour sécuriser un site web quand on a peu de temps

La question qu'on me pose le plus souvent n'est pas « comment sécuriser », mais « par quoi je commence ». Franchement, c'est la bonne question. Parce que la liste des choses à faire est infinie, et que votre temps ne l'est pas.

Voici l'ordre dans lequel j'intervins sur un site que je découvre. Ce n'est pas l'ordre théorique des manuels, c'est celui qui réduit le risque le plus vite.

Priorité 1 : les mises à jour, sans exception

Sur les sites que j'ai eu à nettoyer après intrusion, la porte d'entrée était presque toujours la même : un composant non mis à jour. Un CMS en version N-3, une extension premium achetée il y a deux ans et jamais touchée, une bibliothèque JavaScript dont la faille était publique depuis des mois.

Le problème, c'est que la mise à jour fait peur. On se dit : « si je mets à jour, ça va casser ». Et parfois, ça casse. J'ai déjà cassé un site vitrine en passant une version majeure d'un CMS trop vite, un vendredi soir, évidemment. Le lundi, le formulaire de devis ne fonctionnait plus. Depuis, j'ai une règle simple : jamais de mise à jour majeure en production sans test préalable sur une copie.

Pour les correctifs de sécurité critiques, en revanche, on applique tout de suite. Même sans test. Le risque d'attendre est toujours supérieur au risque de casser.

Priorité 2 : les accès

Combien de personnes peuvent se connecter à l'administration de votre site ? Si vous ne connaissez pas la réponse, c'est déjà un problème. Sur un site client que j'ai repris, l'ancien prestataire avait encore un compte administrateur actif deux ans après la fin du contrat. Mot de passe jamais changé.

• Un compte par personne, jamais de compte partagé
• Authentification à deux facteurs sur tous les accès administrateur, sans discussion
• Suppression immédiate des comptes inactifs, y compris ceux des anciens prestataires
• Principe du moindre privilège : un rédacteur n'a pas besoin des droits d'administration
• Un gestionnaire de mots de passe, y compris pour l'équipe technique

Ce dernier point paraît anodin. Il ne l'est pas. La moitié des incidents que je vois commencent par un mot de passe réutilisé ailleurs, retrouvé dans une fuite de données publique.

HTTPS ne suffit pas : ce que personne ne configure

Beaucoup de gens pensent que passer en HTTPS règle le problème de sécurité. C'est faux, et c'est une confusion qui coûte cher.

Le HTTPS chiffre la communication entre le navigateur et le serveur. Il empêche qu'un tiers, sur le même réseau Wi-Fi, lise ce qui circule. C'est indispensable. Mais ça ne protège en rien contre une injection SQL, une faille dans votre code, ou un formulaire qui accepte n'importe quoi.

Les en-têtes de sécurité, ces oubliés

Voilà ce qui manque sur la grande majorité des sites que j'audite. Des lignes de configuration serveur qui prennent dix minutes à mettre en place et bloquent des catégories entières d'attaques.

• Content-Security-Policy : indique au navigateur quelles sources de scripts sont autorisées. Sans elle, une injection de script dans un commentaire peut s'exécuter chez vos visiteurs.
• HSTS : force le navigateur à toujours utiliser HTTPS, même si l'utilisateur tape une adresse en http://. Empêche les attaques de rétrogradation.
• X-Frame-Options : empêche qu'on affiche votre site dans une iframe invisible pour vous faire cliquer sur des éléments sans le savoir.
• Permissions-Policy : limite l'accès à la caméra, au micro, à la géolocalisation.
• X-Content-Type-Options avec la valeur nosniff : évite qu'un navigateur interprète un fichier image comme du code exécutable.

Sur un site que j'ai repris, l'ajout d'une CSP correcte a fait tomber d'un coup plusieurs tentatives d'injection de script repérées dans les logs. Pas de magie, juste une règle appliquée côté navigateur.

Comment vérifier la sécurité d'un site Internet sans être expert

Vous n'avez pas besoin de compétences en cybersécurité pour faire un premier contrôle. Plusieurs outils en ligne permettent de tester la sécurité d'un site web en quelques secondes. Ils envoient des requêtes, regardent ce que le serveur répond, et listent ce qui manque.

Ce que ces outils vérifient concrètement :

1. La validité et la date d'expiration du certificat TLS
2. La présence ou l'absence des en-têtes de sécurité listés plus haut
3. Les versions logicielles exposées publiquement (parfois trop bavardes)
4. L'ouverture de ports qui ne devraient pas l'être
5. Des comportements suspects sur les formulaires

Attention : un bon score sur ces outils ne veut pas dire que votre site est sûr. Il veut dire qu'il ne présente pas les faiblesses les plus évidentes. Un site peut afficher un A+ et se faire vider par une faille dans une extension.

Un site pour vérifier si un site est fiable, ça existe vraiment ?

Oui, jusqu'à un certain point. Pour savoir si un site marchand est fiable avant d'y laisser vos données bancaires, il y a des signaux simples à regarder : la présence de mentions légales complètes, une adresse physique vérifiable, un numéro de SIRET cohérent, et surtout des conditions générales de vente qui ne sont pas du copier-coller.

Le cadenas dans la barre d'adresse ne prouve qu'une chose : la connexion est chiffrée. Un site d'arnaque peut très bien avoir un certificat valide. C'est même devenu la norme chez les escrocs, et c'est ce qui rend le cadenas trompeur pour le grand public.

La faille que tout le monde ignore : vos dépendances

Votre site n'est pas un bloc. C'est un assemblage de briques écrites par d'autres. Un thème, cinq extensions, une bibliothèque de carrousel, un module de paiement, parfois deux cents paquets npm pour un simple site vitrine.

Chacune de ces briques peut avoir une vulnérabilité publiée. Et vous ne le saurez pas, à moins de le chercher.

Type de dépendance	Fréquence de mise à jour	Risque si négligée	Effort de suivi
CMS principal	Mensuelle à trimestrielle	Élevé : cible numéro un	Faible si les tests sont automatisés
Extensions / plugins	À chaque correctif de sécurité	Très élevé : porte d'entrée favorite	Moyen, dépend du nombre
Bibliothèques front-end	Trimestrielle	Moyen, souvent côté client	Faible avec un outil d'analyse
Dépendances serveur	Au fil des CVE	Élevé, accès direct au système	Élevé sans automatisation
Services tiers (paiement, analytics)	Suivi par le fournisseur	Faible si le fournisseur est sérieux	Nul, mais à vérifier

Sur un projet que j'ai suivi, une bibliothèque de traitement d'images utilisée pour redimensionner les photos des utilisateurs avait une faille connue depuis plusieurs mois. Personne ne s'en était occupé parce que personne ne savait qu'elle était là. Le développeur qui l'avait ajoutée était parti depuis longtemps.

La bonne pratique, c'est de générer régulièrement un inventaire de tout ce qui entre dans votre site. Certaines équipes appellent ça un SBOM, une nomenclature logicielle. Le nom importe peu. Ce qui compte, c'est de savoir ce que vous faites tourner, et de vérifier régulièrement si une alerte est sortie sur l'un de ces composants.

Sauvegardes et réponse à incident : ce qui se passe après

La prévention, c'est bien. Mais tôt ou tard, quelque chose passe. Et c'est là que la plupart des sites se retrouvent nus.

Une sauvegarde qui n'a jamais été testée n'existe pas

J'ai vu des hébergeurs facturer des sauvegardes quotidiennes pendant des années sans que personne ne vérifie qu'elles étaient restaurables. Le jour où il a fallu restaurer, le fichier était corrompu depuis des mois. Trois ans de sauvegardes, zéro utilisable.

Ma règle : toute sauvegarde doit être restaurée au moins une fois, sur un environnement séparé, avant qu'on puisse dire qu'elle existe. Une fois par trimestre minimum. Et les sauvegardes doivent être stockées ailleurs que sur le serveur lui-même, sinon un rançongiciel les chiffre avec le reste.

Que faire quand le site est compromis ?

L'ordre des opérations compte. Dans le feu de l'action, on a tendance à tout faire en même temps, et c'est souvent ce qui aggrave la situation.

1. Isoler sans supprimer : couper l'accès public, mais garder les fichiers et les logs. Supprimer les preuves rend l'analyse impossible.
2. Changer tous les mots de passe : hébergement, base de données, comptes administrateurs, boîtes mail liées.
3. Identifier la porte d'entrée : sans ça, vous serez compromis à nouveau dans les jours qui suivent.
4. Restaurer depuis une sauvegarde antérieure à l'intrusion, après avoir corrigé la faille.
5. Vérifier l'obligation de notification : en cas de fuite de données personnelles, le règlement européen impose une déclaration à l'autorité de contrôle dans les 72 heures. Ce n'est pas une option.

Le point 3 est celui que tout le monde saute. Restaurer sans comprendre comment l'attaquant est entré revient à remettre la clé sous le paillasson.

Ce que recommandent les autorités, et pourquoi ça change tout

En France, l'Anssi publie des recommandations pour la sécurisation des sites web qui sont parmi les plus claires que je connaisse. Leur approche tranche avec la soupe commerciale qu'on trouve ailleurs : pas de promesse de solution miracle, mais une méthode par étapes, adaptée au niveau de sensibilité du site.

L'idée centrale est simple. On ne sécurise pas un site vitrine de trois pages comme une plateforme de santé qui manipule des dossiers médicaux. Le niveau d'exigence doit correspondre à ce que vous protégez. Une PME avec une boutique en ligne n'a pas les mêmes contraintes qu'un service public, mais elle a les mêmes obligations de base : protéger les données de ses clients.

Ce que retiennent la plupart des équipes qui suivent ces recommandations :

• Cartographier ce qu'on protège avant de choisir des outils
• Appliquer une hygiène de base irréprochable plutôt qu'empiler des solutions sophistiquées
• Prévoir la détection, pas seulement la protection
• Documenter, pour que la connaissance ne parte pas avec la personne qui l'a acquise

Ce dernier point me paraît le plus important, et c'est aussi celui qu'on néglige le plus. Sur les sites que j'ai repris en urgence, la moitié du temps perdu venait de l'absence de documentation. Personne ne savait quels services étaient installés, qui avait les accès, ni ce qui avait été modifié la dernière fois.

La sécurité d'un site web n'est pas un état qu'on atteint une fois pour toutes. C'est une habitude, une série de petites vérifications régulières, souvent ennuyeuses. La bonne nouvelle, c'est que les attaques les plus courantes sont aussi les plus simples à contrer. La mauvaise, c'est que personne ne s'y met avant d'avoir eu peur.

Peut-être que la vraie question n'est pas « comment sécuriser mon site », mais « combien de temps je peux encore me permettre d'attendre ». La réponse, en général, est : moins que ce que vous croyez.