Sécurité web : les pratiques qui évitent la plupart des incidents
La plupart des compromissions de sites web ne sont pas ciblées. Ce sont des scanners automatisés qui trouvent une vulnérabilité connue dans un logiciel obsolète, ou un mot de passe réutilisé sur un compte d'administration. Se défendre contre les attaques ordinaires couvre la grande majorité du risque réel.
Ce guide couvre les pratiques qui évitent la plupart des incidents, à peu près par ordre d'effet, et quoi faire si un site est déjà compromis.
Les mesures qui évitent la plupart des incidents#
Par ordre de risque supprimé par unité d'effort.
- Gardez les logiciels à jour. L'écrasante majorité des compromissions exploite une vulnérabilité pour laquelle un correctif existe. Ce seul point pèse plus que tout ce qui suit.
- Des mots de passe uniques et forts plus une authentification à deux facteurs sur chaque compte d'administration, panneau d'hébergement, bureau d'enregistrement et compte e-mail.
- Moindre privilège. Les personnes qui rédigent n'ont pas besoin de comptes administrateur. Supprimez les comptes quand les gens partent.
- HTTPS partout, avec HSTS une fois que vous êtes certain que chaque sous-ressource est disponible en TLS.
- Des sauvegardes testées, stockées hors du serveur. Une sauvegarde sur la machine compromise est chiffrée avec tout le reste.
- Restreignez l'administration par IP quand c'est praticable, et limitez toujours les tentatives de connexion.
- Supprimez ce que vous n'utilisez pas. Chaque extension inactive, thème et ancienne installation est une surface d'attaque sans bénéfice.
Les anciennes installations oubliées — une copie de préproduction en /ancien, un blog de test dans un sous-dossier — sont un point d'entrée courant précisément parce que personne ne les met à jour.
Entrée, sortie et les vulnérabilités classiques#
Ce sont des responsabilités de développement et elles expliquent l'essentiel des vulnérabilités qui ne sont pas « vous n'avez pas mis à jour ».
| Vulnérabilité | Ce qu'elle fait | Prévention |
|---|---|---|
| Injection SQL | Lit ou détruit votre base de données | Requêtes paramétrées, toujours ; jamais de concaténation de chaînes |
| Cross-site scripting | Exécute un script de l'attaquant dans la session d'un visiteur | Échapper à la sortie selon le contexte ; une Content-Security-Policy stricte |
| Cross-site request forgery | Exécute des actions au nom d'un utilisateur connecté | Des jetons par session sur chaque requête modifiant l'état |
| Abus d'envoi de fichiers | Téléverse et exécute du code | Valider le type par le contenu, stocker hors de la racine web, ne jamais exécuter |
| Contrôle d'accès défaillant | Des utilisateurs atteignent des données qui ne sont pas les leurs | Vérifier l'autorisation côté serveur à chaque requête, pas dans l'interface |
| Exposition de données sensibles | Fuite de clés et d'identifiants | Variables d'environnement, jamais dans le dépôt |
| Server-side request forgery | Fait appeler des systèmes internes par votre serveur | Liste d'autorisation des destinations sortantes |
Configuration et en-têtes#
Des mesures peu coûteuses qui ferment des catégories entières de problèmes, la plupart applicables en quelques minutes.
- Servez des en-têtes de sécurité : Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, X-Frame-Options.
- Désactivez le listage de répertoires ; assurez-vous que /.git, /.env et les fichiers de sauvegarde ne sont pas accessibles en HTTP.
- Désactivez l'affichage détaillé des erreurs en production : les traces d'exécution sont de la reconnaissance.
- Bloquez l'accès aux chemins d'administration et de configuration depuis l'internet public quand vous le pouvez.
- Posez les cookies avec HttpOnly, Secure et une valeur SameSite appropriée.
- Gardez les dépendances auditées ; une bibliothèque vulnérable dans votre build est votre vulnérabilité.
- Journalisez les événements d'authentification et alertez sur les schémas inhabituels.
Si le site est déjà compromis#
L'ordre compte ici. Nettoyer les fichiers avant de renouveler les identifiants signifie que l'attaquant revient simplement par la même porte.
- Mettez le site hors ligne ou en mode maintenance. Ne le laissez pas servir des logiciels malveillants aux visiteurs.
- Préservez les preuves : copiez les journaux et un instantané des fichiers avant de changer quoi que ce soit.
- Renouvelez chaque identifiant : hébergement, base de données, comptes d'administration, clés d'API, e-mail. Supposez que tous sont connus.
- Restaurez depuis une sauvegarde antérieure à la compromission, si vous pouvez en identifier une de façon fiable.
- Si vous ne pouvez pas, reconstruisez depuis les sources et n'importez que des données, jamais des fichiers d'origine inconnue.
- Corrigez la vulnérabilité qui leur a permis d'entrer. Sans cette étape vous répéterez tout le processus.
- Cherchez la persistance : tâches planifiées, comptes d'administration supplémentaires, fichiers du cœur modifiés, contenu injecté.
- Demandez un examen dans la Search Console si le site a été signalé, et cherchez des pages de spam injectées.
- Notifiez les utilisateurs concernés si des données personnelles ont été exposées — dans de nombreuses juridictions dans un délai légal.
Restaurer une sauvegarde sans corriger le point d'entrée est la raison la plus fréquente pour laquelle des sites sont compromis deux fois en quinze jours.
Questions fréquentes
Une extension de sécurité suffit-elle ?
Elle aide sur quelques points — limitation des tentatives de connexion, surveillance des modifications de fichiers, un pare-feu basique — et elle ne remplace pas les mises à jour, des identifiants forts et le moindre privilège. Un site avec une extension de sécurité et dix-huit mois de mises à jour manquées n'est pas sécurisé. Réglez d'abord les fondamentaux, puis ajoutez de l'outillage.
Les petits sites sont-ils vraiment attaqués ?
Constamment, et pas à cause de qui vous êtes. Des scanners automatisés testent chaque hôte accessible pour des vulnérabilités connues ; les petits sites sont attractifs précisément parce qu'ils ont moins de chances d'être corrigés. Les petits sites compromis servent au spam, à des pages d'hameçonnage et à des redirections, c'est pourquoi le niveau de trafic de votre site est sans rapport avec le risque.
Où faut-il stocker les sauvegardes ?
Quelque part où le serveur web ne peut pas écrire, idéalement chez un autre fournisseur, avec au moins une copie que les identifiants qui font tourner le site ne peuvent pas supprimer. Les rançongiciels et les attaques destructrices visent spécifiquement les sauvegardes accessibles depuis la machine compromise, et c'est exactement le moment où vous en avez besoin.
Quelle est la mesure de sécurité la plus rentable ?
Appliquer les mises à jour rapidement. C'est peu spectaculaire et cela évite plus de compromissions réelles que tout le reste réuni, car les attaques qui se produisent vraiment sont l'exploitation automatisée de vulnérabilités connues et déjà corrigées. En deuxième, l'authentification à deux facteurs sur les comptes d'administration et d'hébergement.
sécurité site website web piratébonnes pratiques sécuritéinjection sqlxsssauvegardes site web
