Sécuriser un site, bonnes pratiques et ressources pour les pros et les gestionnaires

Le sujet site sécurité n’a jamais été aussi concret pour une PME, une association ou un gestionnaire web qui dépend de son site pour vendre, informer ou collecter des données. Les alertes publiées par CERT-FR, les vulnérabilités CVE qui tombent chaque semaine et les campagnes automatisées contre WordPress, plugins et serveurs mal maintenus rappellent une chose simple, un site compromis n’est pas un incident théorique. C’est une perte de service, de confiance et parfois une obligation de notification RGPD. L’objectif n’est donc pas de transformer ton site en forteresse ingérable. Il est de traiter vite les priorités, dans le bon ordre.

Actions prioritaires pour améliorer la sécurité du site

Si tu n’as que deux heures devant toi, commence ici. Les mesures ci-dessous ne règlent pas tout, mais elles réduisent immédiatement une grande partie du risque courant observé sur les sites PME. L’idée est simple, corriger les expositions évidentes avant de lancer un audit plus large.

1. Mettre à jour le CMS, les plugins et les dépendances, temps estimé 30 à 60 min, impact élevé, source CERT-FR et ANSSI. Les vulnérabilités connues sont les plus exploitées.
2. Activer l’authentification multifacteur sur les comptes sensibles, temps estimé 15 à 30 min, impact élevé, source ANSSI. C’est l’un des gains les plus rapides contre le vol d’accès.
3. Vérifier les sauvegardes et tester une restauration, temps estimé 30 à 90 min, impact élevé, source KB et bonnes pratiques CERT-FR. Une sauvegarde non testée reste une promesse.
4. Forcer HTTPS et contrôler TLS, temps estimé 20 à 40 min, impact élevé, source ANSSI. Sans chiffrement correct, tu cumules risque technique et perte de confiance.
5. Supprimer les comptes inutiles et réduire les privilèges, temps estimé 20 min, impact moyen à élevé, source ANSSI. Trop d’accès admin créent trop de portes d’entrée.
6. Installer une journalisation minimale et une alerte d’erreur, temps estimé 30 à 45 min, impact moyen, source CERT-FR et KB. Sans logs exploitables, tu découvres souvent l’incident trop tard.
7. Scanner rapidement le site et l’infrastructure exposée, temps estimé 30 à 60 min, impact moyen à élevé, source CERT-FR, OWASP et KB. Cela aide à repérer les oublis grossiers avant qu’un attaquant ne le fasse.

Comment réaliser un audit de sécurité du site express

Une fois les urgences traitées, il faut cadrer l’audit. Beaucoup de structures scannent l’URL publique puis s’arrêtent là. C’est insuffisant. Un site web, c’est aussi un hébergement, des accès administrateur, un CDN, des API, des plugins, des sauvegardes et parfois un espace client relié à des données personnelles.

Préparation et périmètre

Le périmètre doit être défini avant le premier test. Sinon, tu confonds vitrine, back-office, API, staging et production, puis tu oublies la moitié des dépendances. Si des données personnelles sont traitées, le RGPD entre aussi dans la discussion, notamment pour la sécurité des traitements, la traçabilité et la notification en cas de fuite.

• Nom de domaine public, avec sous-domaines critiques et redirections.
• Hébergement, serveur, mutualisé, VPS, cloud managé ou conteneurs.
• CDN, WAF et DNS, souvent oubliés alors qu’ils exposent une partie de la surface.
• CMS, plugins, thèmes et modules, surtout sur WordPress ou Prestashop.
• API et formulaires, souvent plus fragiles que les pages visibles.
• Sauvegardes et accès d’administration, y compris FTP, SSH, base SQL et comptes support.

Outils recommandés

Les outils ne remplacent pas l’analyse, mais ils font gagner un temps énorme quand ils sont bien choisis. Le bon mix combine un scanner infrastructure, un scanner web, une analyse de dépendances et quelques vérifications manuelles très ciblées.

Vérifications rapides en 10 minutes

Avant de partir dans des scans lourds, fais une passe express. Elle suffit souvent à repérer les oublis les plus coûteux.

• TLS valide, action corrective, renouveler le certificat et vérifier la chaîne complète.
• Redirection HTTP vers HTTPS, action corrective, forcer la redirection côté serveur ou proxy.
• HSTS en place, action corrective, ajouter un header strict si ton site est entièrement en HTTPS.
• Content-Security-Policy basique, action corrective, poser une politique simple puis l’affiner.
• Plugins obsolètes, action corrective, mettre à jour ou supprimer immédiatement.
• Permissions de fichiers trop larges, action corrective, revoir chmod et propriétaire des fichiers.
• Comptes admin dormants, action corrective, désactiver ou supprimer les accès non utilisés.
• Sauvegardes testées, action corrective, restaurer sur un environnement de test au moins une fois.

Vulnérabilités fréquentes et comment les corriger

Le gain réel vient ensuite des vulnérabilités courantes. Inutile de fantasmer une attaque ultra sophistiquée si le site expose encore une injection simple, un plugin abandonné ou un accès admin sans MFA. Les failles classiques restent les plus rentables pour les attaquants. C’est pour cela qu’elles reviennent partout, du rapport de terrain au résumé de l’OWASP Top 10.

OWASP Top 10, version résumé

• Contrôle d’accès cassé, correction immédiate, revoir les rôles et tester les accès non autorisés.
• Défaillances cryptographiques, correction immédiate, forcer TLS correct et chiffrer les données sensibles.
• Injection, correction immédiate, utiliser requêtes paramétrées et validation stricte des entrées.
• Conception non sécurisée, correction immédiate, revoir les flux critiques avant d’ajouter des rustines.
• Mauvaise configuration de sécurité, correction immédiate, désactiver les services inutiles et durcir les paramètres par défaut.
• Composants vulnérables ou obsolètes, correction immédiate, patcher vite et suivre les dépendances.
• Défauts d’identification et d’authentification, correction immédiate, MFA, verrouillage et mots de passe robustes.
• Intégrité logicielle compromise, correction immédiate, contrôler la chaîne de déploiement et les packages.
• Journalisation et monitoring insuffisants, correction immédiate, centraliser logs et alertes.
• SSRF et requêtes côté serveur non maîtrisées, correction immédiate, filtrer strictement les destinations et usages internes.

Vulnérabilités liées à l'hébergement et à l'infrastructure

Au-delà du code, beaucoup d’incidents viennent d’un environnement trop permissif. Versions PHP anciennes, ports exposés sans raison, accès SSH faibles, sauvegardes stockées sur le même serveur, comptes mutualisés mal isolés, tout cela continue de faire des dégâts. Le durcissement serveur n’est pas spectaculaire. Il évite pourtant une grande partie des compromissions banales.

• Fermer les ports inutiles et vérifier régulièrement l’exposition réelle.
• Mettre à jour PHP, Nginx, Apache et l’OS, surtout après publication d’une CVE critique.
• Isoler les comptes et environnements, production, staging et comptes clients séparés si possible.
• Déporter les sauvegardes hors site, pour éviter leur perte dans la même compromission.
• Désactiver l’authentification faible, notamment les accès FTP non chiffrés.
• Contrôler les permissions et propriétaires, pour limiter l’impact d’un webshell ou d’un plugin compromis.

Durcissement et bonnes pratiques opérationnelles

Une fois les failles les plus fréquentes traitées, il faut stabiliser l’exploitation. C’est là que beaucoup d’équipes décrochent. Elles corrigent l’urgence, puis reviennent à un mode de gestion trop artisanal. La sécurité site web devient durable seulement si elle entre dans la routine.

Configuration serveur et TLS

Le sujet TLS paraît parfois secondaire parce qu’il est déjà “vert dans le navigateur”. C’est une erreur. Un site moderne doit désactiver les versions trop anciennes, automatiser le renouvellement des certificats et contrôler régulièrement sa configuration avec un service comme SSL Labs. Let’s Encrypt via ACME simplifie déjà beaucoup ce travail. Il faut en profiter.

• Désactiver TLS anciens si l’environnement le permet encore.
• Renouveler automatiquement les certificats avec ACME ou un équivalent.
• Forcer HTTPS partout, y compris en back-office si possible.
• Tester régulièrement la configuration avec un audit externe simple.
• Documenter les réglages pour éviter une régression après migration.

Protection applicative

Le durcissement applicatif combine plusieurs couches très simples, WAF, limitation de débit, protection bruteforce, nettoyage des plugins et principe du moindre privilège. Aucun de ces éléments n’est magique seul. Ensemble, ils changent beaucoup la résilience du site face aux attaques de masse.

• Activer un WAF sur le front web ou via un CDN sérieux.
• Mettre en place du rate limiting sur login, API et formulaires sensibles.
• Bloquer les bruteforces avec MFA, limitation de tentatives et journalisation.
• Supprimer les plugins et thèmes inutilisés, pas seulement les désactiver.
• Appliquer le moindre privilège pour comptes CMS, base de données et support.

Processus de patching et gestion des vulnérabilités

Le patching efficace n’est pas juste une mise à jour quand on y pense. C’est un cycle. Tu identifies la faille, tu qualifies l’impact, tu testes, tu déploies, puis tu gardes une capacité de rollback si le correctif casse quelque chose.

Surveillance, réponse et remontée d'incident

À ce stade, le site est mieux protégé. Il n’est pas invulnérable. C’est pour cela que la détection et la réponse comptent autant que la prévention. Une équipe qui voit vite un incident limite souvent les dégâts sans budget démesuré.

Détection et monitoring

Il faut collecter ce qui sert vraiment. Les logs d’accès, d’erreur et d’authentification sont le minimum vital. Sur Linux, cela peut vouloir dire regarder par exemple /var/log/nginx/access.log, /var/log/nginx/error.log, /var/log/auth.log ou leurs équivalents. Même un SIEM léger ou une centralisation simple améliore déjà énormément la visibilité.

1. Logs d’accès web, pour repérer scans, pics anormaux et requêtes suspectes.
2. Logs d’erreur applicative, utiles pour détecter plugins cassés ou comportements nouveaux.
3. Logs d’authentification, pour suivre tentatives SSH, admin CMS ou SSO.
4. Alertes sur changements de fichiers, très utiles sur WordPress.
5. Veille CERT-FR et CVE, à consulter au moins chaque semaine.
6. Revue régulière, hebdomadaire pour petit site critique, plus fréquente si exposition forte.

Plan de réponse incident, RACI simplifié

Quand le site est compromis, le pire réflexe consiste à improviser. Il faut une petite matrice claire, qui fait quoi, dans quel délai, avec quel message minimum. Même une structure de cinq personnes peut avoir un plan utile.

Remontée aux autorités et obligations légales

Si l’incident touche des données personnelles, la CNIL peut devoir être notifiée dans les délais prévus par le RGPD, typiquement 72 heures après la prise de connaissance de la violation, selon le niveau de risque. CERT-FR n’est pas un support de proximité pour toutes les petites alertes banales, mais ses publications, bulletins et ressources restent précieuses pour comprendre une campagne active ou qualifier une faille importante. L’hébergeur, le prestataire d’infogérance, le DPO et parfois l’assureur cyber doivent aussi entrer dans la boucle très tôt. La qualité de la traçabilité compte autant que la correction technique.

Ressources et références françaises et outils pratiques

Une bonne feuille de route gagne du temps si elle s’appuie sur quelques références stables. Inutile d’empiler cinquante favoris. Huit ressources bien choisies suffisent largement pour une équipe PME.

• CERT-FR, utilité, alertes et bulletins de sécurité, type site officiel, à consulter pour la veille vulnérabilités.
• ANSSI, utilité, guides de durcissement et recommandations, type référentiel, très utile pour structurer les bases.
• CNIL, utilité, violation de données et obligations RGPD, type site officiel, à lire avant incident si possible.
• OWASP Top 10, utilité, résumé des risques applicatifs, type référence, excellent support de vulgarisation technique.
• OWASP ZAP, utilité, scanner applicatif, type outil, bon premier niveau de test.
• OpenVAS, utilité, scan infrastructure, type outil, intéressant pour audit plus large.
• securityheaders.io, utilité, contrôle des en-têtes, type outil web, très rapide pour une première passe.
• WP-CLI, utilité, maintenance et dépannage WordPress, type outil ligne de commande, très pratique en incident.

Cas pratique court, dépannage d'une compromission WordPress

Le cas WordPress mérite un traitement à part, parce qu’il concentre beaucoup d’incidents PME, souvent à cause d’un plugin obsolète, d’un mot de passe faible ou d’une permission trop large. La bonne réponse n’est pas de bricoler directement en production sans méthode. Il faut suivre une séquence claire.

1. Passer le site en maintenance ou limiter l’accès, pour freiner l’exploitation en cours.
2. Sauvegarder les fichiers et la base, même compromis, avant toute suppression.
3. Identifier les symptômes, redirections étranges, fichiers inconnus, admin créé, spam SEO, charge CPU anormale.
4. Scanner l’arborescence et rechercher les fichiers suspects avec grep, find ou un outil sécurité adapté.
5. Lister plugins et thèmes avec wp plugin list et retirer les composants abandonnés ou compromis.
6. Réinitialiser tous les mots de passe, admin WordPress, base, FTP, SSH, hébergeur.
7. Remettre les permissions propres, par exemple via chown et chmod adaptés au contexte.
8. Restaurer depuis une sauvegarde saine si l’infection est trop large ou ancienne.
9. Mettre à jour entièrement le cœur, les thèmes, les plugins et les dépendances.
10. Vérifier les logs puis rouvrir progressivement, avec surveillance renforcée pendant plusieurs jours.

Coûts et priorisation pour une PME

La sécurité n’est pas gratuite, mais elle n’exige pas non plus un budget de grand groupe pour devenir sérieuse. Le plus utile est de financer d’abord la continuité minimale, sauvegarde, mises à jour, visibilité, protection applicative légère, puis d’ajouter un audit ponctuel si le site devient plus critique. C’est exactement la logique de priorisation qu’une PME peut tenir dans la durée.

Commencer simple, corriger vite, documenter toujours

Le meilleur plan site sécurité pour une PME n’est pas celui qui accumule les outils ou les sigles. C’est celui qui traite les failles les plus probables dans un ordre cohérent, garde des sauvegardes testées, documente les accès et sait quoi faire le jour où quelque chose tourne mal. Les ressources françaises comme CERT-FR, ANSSI et la CNIL offrent déjà une base solide pour décider sans improviser. Si tu dois prioriser, commence par mises à jour, MFA, sauvegardes, HTTPS, logs et réduction des privilèges. C’est rarement glamour. C’est presque toujours ce qui protège le mieux.