Sécurité des sites Web : comment les sites sont piratés et comment l'arrêter

Pourquoi même les petits sites sont attaqués

Commençons par la croyance que nous entendons dans presque chaque première réunion : "Qui s'occuperait de nous ? Nous avons cinq pages et recevons trois demandes par semaine." Cela semble raisonnable. C'est aussi exactement pourquoi des sites comme celui-ci sont souvent compromis.

Personne ne vous a choisi. La grande majorité des attaques contre les petites et moyennes entreprises ne sont pas du tout personnelles. Le logiciel fait le travail : il prend des listes de domaines et d'adresses IP, les parcourt un par un et teste chacun pour des dizaines de faiblesses connues. Le bot n'a aucune idée de si vous êtes une clinique dentaire ou un studio de céramique. Il lit une chaîne de version dans la réponse du serveur, vérifie sa liste et passe à autre chose s'il n'y a pas de correspondance. S'il y a une correspondance, il se met au travail.

C'est l'équivalent de marcher dans une rue en tirant sur les poignées de porte des voitures. Personne n'a choisi votre voiture. La vôtre était simplement déverrouillée.

Quelle est la valeur d'un site vitrine

Un attaquant ne veut presque jamais blesser vous spécifiquement. Un site compromis a une valeur marchande, et cela provient de plusieurs choses à la fois :

• Équité des liens. Des liens cachés ou des sections entières cachées sur les casinos, les prêts ou les pharmacies sont discrètement injectés dans vos pages. Vous ne les voyez pas. Les moteurs de recherche, eux, les voient.
• Trafic. Vos visiteurs sont redirigés ailleurs — mais pas tous. Souvent, seuls les utilisateurs mobiles, ceux arrivant par recherche, et seulement une fois par jour par personne. C'est précisément pourquoi vous pouvez visiter votre propre site depuis votre propre ordinateur portable pendant des mois et ne rien remarquer.
• Ressources serveur. Votre hébergement devient un nœud pour envoyer du spam, miner ou attaquer d'autres sites.
• Données. Une base de données de demandes, numéros de téléphone, adresses et e-mails est un produit avec des acheteurs. Même si tout ce que vous avez est "juste un formulaire de contact".
• Extorsion. Les fichiers sont cryptés ou supprimés, et vous êtes invité à payer pour leur retour.

Ce qui conduit à la conclusion qui change la façon dont tout ce sujet se ressent : la sécurité des sites web ne consiste pas à se défendre contre un génie en hoodie. C'est une hygiène qui vous éloigne du pool des cibles faciles. Un bot ne passera pas de temps sur un site bien entretenu pendant qu'un millier de sites négligés se trouvent à côté.

Comment les propriétaires découvrent généralement

Les symptômes ne viennent presque jamais de vous. Votre hôte envoie des e-mails concernant une activité suspecte. Google Search Console signale un avertissement. Un client appelle pour dire que son navigateur lui crie dessus. L'e-mail de l'entreprise atterrit soudainement dans le dossier spam de tout le monde. Le trafic de recherche chute sans explication. Si l'un de ces événements s'est produit, vous l'avez découvert trop tard — mais tard n'est pas synonyme de trop tard.

Comment les sites sont réellement compromis

Oubliez les films. En réalité, presque chaque compromission de petite entreprise remonte à une liste courte et remarquablement ennuyeuse. Nous avons nettoyé des dizaines de sites infectés, et le point d'entrée était presque toujours l'un de ceux-ci.

CMS obsolète et plugins avant tout

C'est le grand gagnant. WordPress, Joomla, OpenCart — les plateformes elles-mêmes ne sont pas intrinsèquement vulnérables. L'écosystème est le problème : un plugin de galerie mis à jour pour la dernière fois en 2021, un thème acheté sur un marché dont l'auteur est parti il y a des années, un module de formulaire qu'un sous-traitant a installé et oublié.

Comprenez les mécanismes ici, car ils sont contre-intuitifs. Lorsqu'une vulnérabilité est trouvée dans un plugin, elle est publiée. C'est ainsi que fonctionne l'industrie, et c'est correct. Mais à partir de ce moment, une course commence : le développeur expédie un correctif, et les bots de scan reçoivent l'empreinte de la version vulnérable en quelques heures. Un site qui se met à jour une fois par an n'est pas du tout dans cette course.

Mots de passe faibles, et bien pire, ceux réutilisés

Un mot de passe comme Admin2024! semble fort — lettre majuscule, chiffres, un point d'exclamation. Il figure dans tous les dictionnaires de craquage. Mais ce n'est pas le véritable dommage. Le véritable dommage est le même mot de passe sur votre panneau d'hébergement, votre admin de site, votre e-mail, et un service qui a été compromis il y a deux ans. La fuite de quelqu'un d'autre devient votre identifiant, et techniquement, il n'y a pas de "piratage" du tout. L'attaquant tape simplement un nom d'utilisateur et un mot de passe.

Identifiants volés d'un ordinateur portable du personnel

Le classique que personne ne soupçonne. Les identifiants FTP enregistrés dans un gestionnaire de fichiers sur l'ordinateur portable d'un designer sont lus par un malware ordinaire. Le site est "piraté" via une connexion légitime. Le signe révélateur : vous nettoyez tout soigneusement et l'infection revient dans les deux jours.

Formulaires non protégés et points de terminaison ouverts

Chaque endroit où votre site accepte des entrées de l'extérieur — un formulaire de contact, une recherche sur le site, un téléchargement de fichier, un point de terminaison API — est une porte. Lorsque l'entrée est acceptée sans vérifier son type, sa taille et son contenu, la porte fonctionne dans les deux sens. Le téléchargement de fichiers mérite une peur particulière : permettre à quelqu'un de placer quelque chose sur votre serveur que le serveur exécute ensuite, c'est essentiellement remettre les clés.

Fichiers laissés traîner dans la racine web

Le tueur silencieux, et nous le trouvons constamment. Vivre dans le dossier public : backup.zip de l'agence précédente, dump.sql avec la base de données complète, un .git dossier contenant l'historique complet du projet avec des mots de passe dans les anciens commits, un test.php, un info.php, une copie de configuration nommée config.php.bak. Chacun de ces fichiers est téléchargeable par quiconque devine l'URL. Et les bots ne devinent pas — ils portent des listes des noms habituels et les vérifient en quelques secondes.

Un mot spécifiquement sur .bak et .ancien extensions : le serveur ne les exécute pas en tant que code, il les sert en tant que texte brut. Cela signifie qu'il remet directement votre mot de passe de base de données au navigateur.

Projets Oubliés et Abandonnés

Une ancienne page de destination de campagne sur un sous-domaine. Une copie de staging construite il y a deux ans et jamais supprimée. Un forum que personne n'utilise. Ils ne sont jamais mis à jour car personne ne se souvient qu'ils existent. Et ils restent généralement dans le même compte d'hébergement — donc compromettre une page de destination oubliée remet les fichiers de votre site principal. Nous commençons chaque audit par "qu'est-ce qui vit d'autre dans ce compte ?", et la réponse surprend régulièrement le propriétaire plus que quiconque.

HTTPS et SSL : Plus un sujet de débat

Si vous n'avez pas HTTPS, arrêtez de lire et corrigez cela d'abord. En 2026, un site sans cryptage n'est pas économique. C'est une faute.

Ce que fait réellement un certificat SSL

Sans HTTPS, les données circulent entre le navigateur de votre visiteur et votre serveur en texte brut. Quiconque positionné le long de ce chemin peut les lire et les modifier : le propriétaire du Wi-Fi du café, un FAI, des équipements sur un réseau intermédiaire. Les lire signifie lire des mots de passe et le contenu des formulaires. Les modifier signifie qu'ils peuvent réécrire votre page ou y injecter leurs propres publicités, et votre visiteur sera certain que cela vient de vous.

Un certificat SSL résout deux problèmes à la fois. Il crypte le canal, et il prouve que le domaine appartient à celui qui le sert. Le second est tout aussi important que le premier : sans identité, le cryptage est inutile, car vous pourriez crypter un canal vers un fraudeur.

Les Détails Qui Comptent Plus Que le Certificat Lui-Même

Les certificats sont maintenant gratuits et automatiques — Let's Encrypt a réglé cette question pour tout le monde. Donc, les erreurs ne concernent plus "en avoir un ou non". Elles sont dans la configuration :

• Redirections. Chaque requête HTTP doit rediriger de manière permanente vers HTTPS. Sinon, l'ancienne version continue simplement de fonctionner aux côtés de la nouvelle.
• Contenu mixte. La page se charge via HTTPS mais récupère une image, une police ou un script via HTTP. Le navigateur se plaint et le cadenas disparaît. Les anciens extraits d'analytique et les widgets tiers sont les coupables habituels.
• Renouvellement automatique. Les certificats ont une durée de vie courte et sont renouvelés par un robot. Lorsque le robot tombe en panne, vous en entendrez parler de la part des clients le pire jour possible. Surveillez la date d'expiration.
• URLs canoniques. Après être passé à HTTPS, assurez-vous que chaque page a une adresse plutôt que quatre variations avec et sans www.

Ce que HTTPS ne fait pas

Ici se trouve une dangereuse idée reçue. Le cadenas ne signifie pas que le site est sûr. Cela signifie exactement une chose : le canal vers le serveur est chiffré. Un site compromis rempli de code malveillant fonctionne très bien sur HTTPS avec le cadenas intact. Les sites de phishing ont aussi des certificats — ils sont délivrés gratuitement et automatiquement à tout le monde. HTTPS est une fondation, pas un toit.

Pour les sites qui gèrent de l'argent, la barre est beaucoup plus haute. Le chiffrement du canal est le ticket d'entrée ; après cela viennent la vérification de la signature du webhook, les opérations idempotentes et la séparation stricte des accès. Nous avons détaillé ce mécanisme en utilisant la passerelle de paiement Payora, où la sécurité des transactions prime sur toutes les autres fonctionnalités de la construction.

En-têtes de sécurité : La défense silencieuse que personne n'active

Les en-têtes de sécurité sont des instructions que votre serveur envoie au navigateur avec la page. Le point est que les navigateurs sont confiants par défaut : ils exécuteront tout script qu'ils trouvent sur votre page et afficheront votre page dans la fenêtre de quelqu'un d'autre si on le leur demande. Les en-têtes sont comment vous dites au navigateur : "ne fais pas ça avec moi."

Leur grande vertu est qu'ils sont gratuits, configurés une fois, et appliqués du côté du visiteur sans charger votre serveur. Leur grand problème est qu'ils sont absents par défaut presque partout.

Content-Security-Policy (CSP)

Le plus puissant et le plus capricieux. C'est une liste blanche : où cette page peut charger des scripts, des styles, des images et des polices. Si un attaquant parvient à injecter un script étranger dans votre page, le navigateur refuse simplement de l'exécuter, car la source n'est pas sur la liste. En effet, le CSP transforme un compromis réussi en un échec.

Un avertissement honnête : précipiter le CSP va casser votre site. Le bon chemin est d'abord le mode rapport uniquement, collecter les violations, puis resserrer. Sur un site avec une douzaine de widgets tiers, cela représente plusieurs jours de travail, pas dix minutes.

Strict-Transport-Security (HSTS)

Indique au navigateur : ce domaine est uniquement HTTPS, souviens-toi de cela pendant un an. Cela comble l'écart entre quelqu'un qui tape une adresse sans préfixe et le redirectionnement qui se déclenche. Cet écart est précisément là où l'interception se produit. Ne l'activez que lorsque vous êtes sûr que HTTPS fonctionne partout et de manière permanente — inverser la décision est lent.

X-Frame-Options

Empêche votre site d'être intégré dans un cadre sur la page de quelqu'un d'autre. Cela défend contre un simple et vilain truc : une couche invisible placée sur votre vrai bouton, de sorte que le clic de l'utilisateur aille quelque part où il n'avait jamais l'intention d'aller. Pour tout site avec un compte client ou un processus de paiement, celui-ci est obligatoire.

X-Content-Type-Options

Une ligne, pas de configuration. Cela interdit au navigateur de deviner le type d'un fichier par rapport à ce que le serveur a déclaré. Sans cela, une image téléchargée peut, dans les bonnes conditions, être interprétée comme un script et exécutée.

Referrer-Policy

Contrôle quelles informations sur votre site le navigateur transmet lorsque un visiteur clique ailleurs. Sans cela, l'URL complète de la page — y compris des paramètres comme un jeton de réinitialisation de mot de passe ou un identifiant interne — se retrouve dans les analyses de quelqu'un d'autre. Ce n'est pas un hack. C'est une fuite : silencieuse et continue.

Permissions-Policy

Désactive ce dont votre site n'a clairement pas besoin : caméra, microphone, géolocalisation, capteurs. La règle est simple : tout ce qui n'est pas utilisé doit être désactivé.

Tout scanner public en ligne évaluera vos en-têtes en une minute, et le résultat est généralement déconcertant. Pour nous, les en-têtes font partie de la construction de base de chaque projet — partie du développement lui-même, pas un supplément payant ajouté plus tard.

Mises à jour et code tiers : Discipline plutôt que héroïsme

Le conseil est ennuyeux : gardez les choses à jour. Le problème est que c'est le seul conseil que tout le monde a entendu et presque personne ne suit. Voyons pourquoi — et comment le rendre efficace.

Pourquoi les mises à jour sont reportées

Pas de paresse. Peur. Une mise à jour a déjà cassé la mise en page, ou le panier a cessé de fonctionner, et le bouton "mettre à jour" a été évité depuis. La peur est rationnelle : les mises à jour peuvent réellement casser des choses, surtout lorsqu'un site est assemblé à partir de plugins qui ont été modifiés directement dans leur source.

Mais faites le calcul. Le risque d'une mise en page cassée vous coûte une heure. Le risque d'un compromis vous coûte une restauration, un nettoyage, des conversations délicates avec des clients, et des mois à récupérer des classements de recherche. Le deuxième risque est d'un ordre de grandeur plus coûteux.

Comment mettre à jour sans panique

1. Faites une sauvegarde avant, pas après.Sauvegarde complète : fichiers et base de données. Ne jamais sauter cette étape, sans exception.
2. Conservez une copie de staging.Un environnement séparé, fermé aux moteurs de recherche et aux étrangers, où les mises à jour sont testées avant d'être mises en ligne. Sur tout projet sérieux, ce n'est pas optionnel.
3. Séparez le critique du routinier.Les mises à jour de sécurité sont appliquées immédiatement. Les mineures selon un calendrier. Les sauts de version majeurs sont leur propre projet avec un plan.
4. Vérifiez les choses importantes après.Soumettez un formulaire, effectuez un paiement, connectez-vous à un compte, regardez-le sur un téléphone. Trois minutes de vérification manuelle économisent des semaines.

Audit du code des autres

Une fois par trimestre, ouvrez votre liste de plugins et posez deux questions. Premièrement : est-ce que cela est utilisé ? Un plugin installé "juste au cas où" est un trou sans fonction. Et notez qu'un plugin désactivé reste dans le système de fichiers et peut toujours être vulnérable — donc les choses inutilisées doivent être supprimées, pas simplement désactivées.

Deuxième : l'auteur est-il vivant ? Si la dernière mise à jour date de trois ans et que la description indique qu'il est compatible avec une version qui est depuis longtemps obsolète, c'est du code abandonné. Il ne deviendra pas plus sûr de lui-même. Trouvez un remplacement calmement, à l'avance, plutôt que la nuit après un compromis.

Et la règle qui mérite d'être encadrée sur le mur : moins il y a de code tiers sur votre site, plus votre surface d'attaque est petite. Chaque plugin est un étranger auquel vous avez silencieusement accordé l'accès à votre serveur.

Hygiène d'accès et d'hébergement : Des gains plus importants que le code

La cause la plus courante d'un compromis dans le monde réel n'est pas une exploitation astucieuse. C'est l'accès éparpillé. C'est aussi là que l'ordre est rétabli le plus rapidement et pour presque rien.

Moins de privilèges

Chaque personne et chaque processus devrait détenir exactement les droits nécessaires à leur travail et pas un de plus. Un gestionnaire de contenu n'a pas besoin de droits d'administrateur ; il a besoin de publier des articles. Un sous-traitant qui édite une page n'a pas besoin de la base de données. Un script qui lit un catalogue n'a pas besoin d'accès en écriture.

Ouvrez votre liste d'utilisateurs administrateurs dès maintenant. Lors des audits, nous trouvons régulièrement des comptes actifs appartenant à des personnes qui sont parties, une agence avec laquelle vous vous êtes séparé il y a un an, et un utilisateur mystérieux appelé admin2 que personne ne peut justifier. Ce dernier n'est pas un oubli — c'est un symptôme.

Un compte par personne

Un partagé adminse connecter avec le mot de passe se trouvant dans un fil de discussion signifie que personne n'est responsable. Quand quelque chose se produit, le journal indique "admin connecté", ce qui ne vous dit absolument rien. Des comptes individuels vous offrent deux choses : un historique lisible de qui a fait quoi, et la possibilité de révoquer l'accès d'une personne sans changer les mots de passe de toute l'entreprise.

Authentification à Deux Facteurs

Si vous mettez en œuvre exactement un élément de tout cet article, faites-en celui-ci. L'authentification à deux facteurs rend un mot de passe volé inutile. Chaque tentative de force brute et chaque violation de tiers ne fonctionnent plus contre vous, car le mot de passe seul n'est plus suffisant. Activez-le partout où il existe : panneau d'hébergement, registraire de domaine, admin de site, email, Cloudflare, GitHub.

Un mot spécial sur le registraire de domaine. C'est le point de défaillance le plus sous-estimé de toute la pile. Perdre le contrôle de votre domaine est pire que de perdre votre site : un site se restaure à partir d'une sauvegarde en une heure, tandis qu'un domaine revient après des mois de tickets de support — s'il revient.

Clés SSH au lieu de mots de passe, et pas de FTP

Un mot de passe peut être deviné ou récupéré d'un ordinateur portable. Une clé ne peut pas être devinée dans un délai utile. La configuration prend quinze minutes une fois, après quoi la connexion par mot de passe au serveur est complètement désactivée.

Séparément : abandonnez le FTP en clair. Il envoie votre nom d'utilisateur et votre mot de passe en texte clair, comme si nous étions en 1998. Utilisez uniquement SFTP ou SSH. Si votre hébergeur propose le FTP comme méthode principale, cela vous en dit long sur l'hébergeur.

Un gestionnaire de mots de passe au lieu de la mémoire

Aucun humain ne peut se souvenir de quarante mots de passe complexes distincts, c'est exactement pourquoi ils les réutilisent. Un gestionnaire de mots de passe élimine complètement le problème : il génère un mot de passe unique par service, les stocke de manière cryptée et vous permet de transmettre des identifiants à un collègue sans les coller dans un messager. Cela coûte une bouchée de pain et prévient une catastrophe.

Formulaires, spam et limitation de taux

Le formulaire de contact est la partie la plus accessible de votre site web. Il est ouvert à tous, fonctionne sans connexion et attend des données. Pas étonnant qu'il subisse le plus d'abus.

Pourquoi le CAPTCHA n'est pas la solution

Le CAPTCHA attrape des scripts primitifs et agace de vrais humains. Le trafic de spam moderne le contourne soit techniquement, soit par le biais de services de résolution où de vraies personnes répondent à des captchas pour des fractions de cent. Pendant ce temps, cela nuit mesurablement à la conversion : certains clients authentiques abandonnent simplement face aux lettres déformées et partent.

L'approche qui fonctionne est superposée et invisible pour le visiteur :

• Honeypot. Un champ caché qu'un humain ne voit jamais ni ne remplit, et qu'un bot remplit automatiquement. Rempli signifie rejeté. Simple, gratuit, efficace contre la majorité.
• Vérifications de timing. Un formulaire soumis une demi-seconde après le chargement de la page n'a pas été rempli par une personne.
• Limitation de taux.Pas plus que quelques soumissions d'une adresse dans une fenêtre donnée. C'est le mécanisme clé, et c'est le même qui protège votre page de connexion contre les tentatives de devinette de mot de passe.
• Notation invisible.Les systèmes modernes évaluent le comportement et ne remettent en question que les demandes qui semblent suspectes. Un véritable client ne voit rien du tout.

La validation côté serveur est non négociable

Une validation élégante des champs dans le navigateur est une commodité pour les utilisateurs, pas une défense. Les données arrivant sur votre serveur peuvent être envoyées sans jamais toucher votre page. Donc, tout est vérifié à nouveau côté serveur : type, longueur, format, valeurs autorisées. La règle est simple et universelle : les entrées du monde extérieur ne sont jamais fiables, même si votre propre script l'a validé il y a un instant.

Les téléchargements de fichiers sont leur propre problème

Si un visiteur peut télécharger un fichier, agissez comme s'il téléchargeait quelque chose d'hostile. Vérifiez le véritable type de contenu, pas l'extension dans le nom. Renommez le fichier vous-même. Limitez la taille. Et surtout, stockez les téléchargements quelque part où le serveur n'exécutera physiquement pas de code — idéalement sur un stockage complètement séparé.

La limitation de taux va au-delà des formulaires

Le même mécanisme doit être appliqué à vos points de terminaison API, à la recherche sur le site, à la réinitialisation de mot de passe et à toute opération coûteuse. Sans cela, un bot persistant peut faire tomber votre serveur par simple répétition. Cela compte le plus là où l'argent est en jeu : sur les projets de paiement, nous limitons toujours la vitesse à laquelle les transactions peuvent être créées — notre article sur l'acceptation des paiements en crypto explique pourquoi cela protège votre comptabilité autant que votre serveur.

Sauvegardes : La seule police d'assurance qui paie toujours

En clair : les sauvegardes comptent plus que tout le reste dans cet article. Chaque autre mesure réduit la probabilité d'une catastrophe. Les sauvegardes décident de la façon dont la catastrophe se termine — une soirée désagréable, ou une entreprise fermée.

La règle 3-2-1

Un classique inventé bien avant nous et toujours inégalé :

• 3 copies de vos données : la version active et deux sauvegardes.
• 2 médias ou plateformes différents — ne mettez pas tout dans le même panier.
• 1 copie hors site, physiquement et administrativement séparé du serveur.

C'est ce dernier point où la plupart des configurations échouent. Une sauvegarde sur le même serveur, ou dans le même compte d'hébergement, n'est pas une sauvegarde. Un attaquant qui s'introduit supprime d'abord cela — c'est une étape standard, pas un effet de style. Les ransomwares l'encryptent avec tout le reste. Et si l'hôte meurt, il meurt aussi.

Une sauvegarde non testée n'est pas une sauvegarde

Voici la partie qui fait mal. Nous continuons à voir la même scène : les sauvegardes ont fonctionné fidèlement pendant deux ans, et le jour où cela compte, les archives s'avèrent corrompues. Ou elles contiennent des fichiers mais pas de base de données. Ou la base de données est là, mais l'export a déformé l'encodage et le texte est des points d'interrogation. Ou l'archive fait 40 kilooctets parce que le script est mort dans le premier dossier et l'email d'erreur est allé dans une boîte de réception que personne ne lit.

La conclusion : les restaurations doivent être répétées. Une fois par trimestre, déployez une copie dans un environnement de staging et examinez-la. Le site se charge-t-il ? La base de données est-elle là ? Les images sont-elles présentes ? Les commandes apparaissent-elles ? C'est le seul moyen de connaître la vérité sur vos sauvegardes à l'avance plutôt que pendant une catastrophe.

La rétention l'emporte sur la fréquence

Une sauvegarde quotidienne avec trois jours de rétention est inutile contre une infection silencieuse. Le code malveillant reste souvent dormant pendant des mois. Au moment où vous le trouvez, les trois copies sont déjà infectées. Gardez la profondeur : quotidienne pendant deux semaines, hebdomadaire pendant quelques mois, mensuelle pendant un an. L'espace disque est incomparablement moins cher qu'un site sans rien à restaurer.

Que sauvegarder

Les fichiers et la base de données sont évidents. Ce qui est souvent oublié, c'est tout le reste : la configuration du serveur, les règles du serveur web, les tâches planifiées, les paramètres DNS, les e-mails. Un bon indicateur est la question : "si l'entreprise d'hébergement disparaissait demain, combien de temps prendrait une reconstruction complète ailleurs ?" Si vous n'avez pas de réponse, votre sauvegarde est incomplète.

Surveillance et journaux : Voyez-le avant que votre client ne le fasse

Les compromissions sont rarement bruyantes. Bien plus souvent, elles sont silencieuses, et c'est tout l'enjeu : plus vous ne le remarquez pas, plus l'actif rapporte de l'argent à celui qui l'a pris. Donc, le travail de surveillance n'est pas de "prendre un hacker". C'est de réduire l'écart entre l'événement et votre prise de conscience.

L'ensemble minimum

• Surveillance de la disponibilité.Un contrôle de disponibilité toutes les minutes avec une alerte. Les services de base sont gratuits et prennent dix minutes à configurer.
• Surveillance de l'intégrité des fichiers.Le système enregistre l'état de vos fichiers et vous informe lorsque quelque chose change. Personne n'a touché au code, et pourtant deux fichiers ont changé à 3 heures du matin — c'est une conversation.
• Expiration SSL et de domaine.Alertes à l'avance, pas après. Un renouvellement de domaine oublié fait plus de mal que la plupart des hacks.
• Google Search Console.Gratuit et obligatoire. Les moteurs de recherche détectent souvent une infection avant le propriétaire, et ils le diront clairement dans la section sécurité.
• Analyse externe des logiciels malveillants.Des vérifications régulières de l'extérieur détectent ce que seul un visiteur voit : redirections, scripts injectés, contenu échangé.

Journaux : Ennuyeux, et là où se trouve la vérité

Les journaux du serveur web enregistrent chaque demande faite à votre site. Par une journée calme, personne ne les veut. Le jour d'un incident, ils sont votre seule source de faits : quand, d'où, ce qui a été demandé exactement, et ce que le serveur a répondu.

Deux choses valent la peine d'être faites à l'avance, car elles ne peuvent pas être faites rétroactivement. Tout d'abord, confirmez que les journaux sont effectivement écrits et conservés pendant au moins un mois. Dans de nombreuses configurations, ils sont tronqués après 24 heures, et il ne reste rien à enquêter. Ensuite, activez la journalisation des connexions administratives — réussies et échouées. Une augmentation des échecs indique une tentative de deviner le mot de passe en direct, et vous pouvez réagir avant que cela ne réussisse.

Que rechercher

Vous n'avez pas besoin d'être un analyste pour repérer l'évident. Des demandes de fichiers que vous n'avez pas et n'avez jamais eus. Des demandes administratives à 3 heures du matin en provenance d'un pays où vous n'employez personne. Une adresse faisant des centaines de demandes en une minute. Une montée des réponses d'erreur là où il n'y en avait pas auparavant. Aucun de ces éléments n'est une preuve à lui seul, mais chacun est une raison d'examiner de plus près.

Nous incluons la surveillance de base dans chaque projet que nous soutenons après le lancement — des exemples de ce travail se trouvent dans notre portefeuille. La leçon n'est pas glamour : un site que personne ne surveille finira par produire une surprise, et la surprise coûte toujours plus cher que la surveillance.

WAF et CDN : Ce que Cloudflare fait et ne fait pas

Cloudflare et des services similaires sont une couche véritablement utile, c'est exactement pourquoi tant de mythes les entourent. Soyons honnêtes sur où se trouve la valeur et où commence l'illusion.

Ce qu'ils sont

Un CDN place un réseau de nœuds dans le monde entier entre votre visiteur et votre serveur. Les fichiers statiques sont servis depuis le nœud le plus proche — le site est plus rapide et votre serveur est soulagé. Un WAF (pare-feu d'application web) est un filtre qui inspecte les demandes entrantes et rejette celles de type attaque avant qu'elles n'atteignent votre code.

La vraie valeur

• Absorber les DDoS. Le trafic indésirable se brise contre le réseau du fournisseur plutôt que contre votre serveur. Une petite entreprise ne survivra pas seule à cette attaque.
• Cacher votre véritable IP de serveur.Les attaques directes deviennent plus difficiles lorsque la cible n'est pas visible.
• Filtrage des bots.Une grande partie du bruit de scan est automatiquement éliminée, et vos journaux deviennent lisibles du jour au lendemain.
• Patching virtuel.Une règle WAF peut bloquer une nouvelle vulnérabilité pendant que vous préparez une mise à jour appropriée. C'est du temps emprunté, pas une solution.
• Vitesse.Un effet secondaire agréable que les visiteurs et les moteurs de recherche remarquent tous les deux.

Ce qu'ils ne feront pas

Maintenant la partie inconfortable. Un WAF ne vous sauvera pas lorsque :

• Votre mot de passe a été volé. Une connexion avec des identifiants valides est une demande légitime. Le filtre la laisse passer, et c'est juste.
• Votre vrai IP est déjà connu et votre serveur accepte des connexions directement, contournant le filtre. C'est une mauvaise configuration extrêmement courante : votre serveur doit accepter le trafic uniquement du réseau du fournisseur.
• Le défaut se trouve dans votre propre logique métier. Si votre code permet à un utilisateur de récupérer la commande d'un autre utilisateur en changeant un numéro, c'est une demande parfaitement bien formée en ce qui concerne le WAF.
• Le code malveillant est déjà à l'intérieur. Le filtre surveille la porte d'entrée, pas ce qui se passe à l'intérieur de la maison.
• Le chiffrement est réglé sur "flexible". Ensuite, le trajet de Cloudflare à votre serveur se fait en texte clair tandis que votre visiteur voit un cadenas et suppose que tout va bien. C'est une imitation dangereuse de la sécurité — utilisez le mode strict avec validation de certificat.

En résumé : un WAF et un CDN sont une excellente clôture de périmètre. Une clôture est inutile lorsque la clé est sous le paillasson et qu'une fenêtre du rez-de-chaussée est ouverte. Cela complète l'hygiène. Cela ne la remplace pas.

Que faire si vous êtes déjà compromis

Restez calme. La panique coûte plus cher que le piratage lui-même : dans une panique, les gens suppriment les choses mêmes dont une enquête a besoin. La procédure est bien établie. Suivez-la.

1. Isoler

Mettez le site derrière une page de maintenance renvoyant un statut 503. Cela protège les visiteurs d'une infection et indique aux moteurs de recherche que l'interruption est temporaire plutôt que terminale. Ne supprimez rien pour l'instant.

2. Préservez les preuves

Contre-intuitif mais critique. Prenez une copie complète du site infecté ainsi que le dernier mois de journauxavanttoute nettoyage. Si vous restaurez à partir d'une sauvegarde sans identifier le point d'entrée, vous serez de nouveau compromis de la même manière, généralement dans la semaine. Cette copie est votre seule chance de comprendre comment ils sont entrés.

3. Faites tourner chaque identifiant

Tous, sans exception, pas de "celui-là ne pouvait définitivement pas avoir fui". Hébergement, SSH, base de données, chaque utilisateur admin, FTP, registraire de domaine, email, services connectés. Activez l'authentification à deux facteurs partout où elle manquait pendant que vous y êtes. Une mise en garde que les gens oublient : faites cela depuis un ordinateur propre. Si l'ordinateur portable est infecté, vos nouveaux mots de passe fuient exactement comme les anciens.

4. Trouvez le point d'entrée

Commencez par les fichiers modifiés à la date de l'infection — la piste la plus rapide. Recherchez dans les journaux quelle requête est arrivée peu avant l'apparition du premier fichier étranger. Vérifiez tout dans le compte d'hébergement, y compris les sous-domaines oubliés. Vérifiez les ordinateurs de tous ceux qui ont accès. Tant que le point d'entrée n'est pas trouvé, l'incident n'est pas clos.

5. Reconstruire

La meilleure solution est une réinstallation propre : un CMS frais, des plugins frais provenant de sources officielles, et uniquement votre contenu et votre base de données récupérés de la sauvegarde — en vérifiant d'abord la base de données, car du code y est également injecté, généralement dans les modèles et les paramètres. Nettoyer manuellement les fichiers infectés est une loterie : si vous en manquez un seul, tout revient.

6. Bouchez le trou et récupérez votre réputation

Corrigez la cause que vous avez identifiée, sinon vous avez simplement remis l'horloge à zéro. Ensuite : demandez une révision dans Google Search Console, vérifiez les enregistrements de messagerie de votre domaine (un site compromis envoyait probablement du spam, et votre domaine peut déjà être sur des listes de blocage), et confirmez qu'il n'y a pas d'administrateurs inconnus restés dans la base de données.

Une note honnête : si votre site prend des paiements ou stocke des données personnelles de clients, improviser est la mauvaise décision. Vous voulez quelqu'un qui a déjà fait cela — contactez-nous. Nous gérons des incidents comme ceux-ci, et plus important encore, nous expliquons ensuite exactement ce qui s'est mal passé et comment s'assurer que cela ne se reproduise pas.

Une liste de contrôle de sécurité pratique

Comprimons tout ce qui précède en une liste sur laquelle vous pouvez commencer dès aujourd'hui. Elle est ordonnée par effet par rapport à l'effort — commencez par le haut.

Aujourd'hui, en une soirée

1. Activez 2FA pour l'hébergement, votre registraire de domaine, l'email et l'administrateur du site.
2. Vérifiez HTTPS fonctionne partout et que toutes les redirections HTTP y mènent.
3. Ouvrez votre liste d'utilisateurs administrateurs et supprimez tous ceux qui ne devraient pas y être: anciens employés, anciens sous-traitants, comptes que personne ne reconnaît.
4. Vérifiez la racine web pour fichiers errants: archives, exports de base de données, un .git dossier, copies de configuration, scripts de test.
5. Confirmer que les sauvegardes existent et ne sont pas stockées sur le même serveur.
6. Connecter le site à Google Search Console et lire la section sécurité.

Cette semaine

1. Configure un gestionnaire de mots de passe et remplacez chaque mot de passe réutilisé par un mot de passe unique.
2. Mettez à jour le CMS et tous les plugins, après avoir effectué une sauvegarde complète.
3. Supprimez les plugins et thèmes inutilisés — supprimez, ne désactivez pas.
4. Configurez en-têtes de sécurité: commencez par X-Content-Type-Options, X-Frame-Options et Referrer-Policy, qui peuvent être activés immédiatement.
5. Désactiver FTP et passez aux clés SSH.
6. Ajouter surveillance de la disponibilité et alertes pour l'expiration SSL et de domaine.
7. Limiter le taux des tentatives de connexion sur le panneau d'administration.

Ce mois-ci

1. Tester une restauration dans un environnement de staging — déployez-le réellement et regardez-le.
2. Mettez un CDN et WAF devant, et fermez l'accès direct au serveur afin que rien ne contourne le filtre.
3. Déployez CSP, en commençant en mode rapport uniquement.
4. Auditez tout dans le compte d'hébergement: sous-domaines, copies de staging, pages d'atterrissage oubliées. Supprimez ce qui n'est pas nécessaire.
5. Configurez la surveillance de l'intégrité des fichiers.
6. Examinez les permissions des fichiers et des dossiers, en supprimant l'accès en écriture là où il n'est pas requis.

En boucle, pour que vous n'ayez plus jamais besoin de cet article

• Hebdomadaire : mises à jour de sécurité, un coup d'œil sur le journal de connexion.
• Mensuel : vérifier les sauvegardes, examiner les utilisateurs, parcourir les journaux.
• Trimestriel : tester la restauration, auditer les plugins, faire tourner les mots de passe des clés.
• Annuel : audit complet, reconsidérer qui a accès et pourquoi.

Une dernière pensée à emporter avec vous. La sécurité n'est pas un état que vous atteignez et oubliez ; c'est une habitude, comme verrouiller la porte du bureau. Personne ne peut garantir une protection absolue, et quiconque le promet vous induit en erreur. Mais la différence entre un site où cette liste est faite et un site où rien n'est fait est la différence entre "quelqu'un a essayé et n'est pas allé loin" et "nous sommes à la troisième semaine de récupération de nos données".

FAQ