Comment Bloquer les Hackers de Votre Site Web : Top Astuces 2026

Personne ne s’assoit devant un clavier pour choisir votre entreprise dans une liste. Ce sont les bots qui choisissent : ils parcourent tout Internet à la recherche d’une page de connexion sans limite de tentatives, d’une extension dont l’exploit est public, ou d’un fichier .env laissé là où le serveur le sert volontiers. Ce qui répond est attaqué, à 3 h du matin, automatiquement, que le site appartienne à une boutique en ligne de Casablanca ou à une clinique de Rabat.

C’est une bonne nouvelle, car cela signifie que la défense est en grande partie mécanique. Ce guide vous montre comment bloquer les hackers de votre site web en 10 étapes, dans l’ordre où nous les appliquons lors d’un vrai chantier de durcissement : un pare-feu en façade, puis les failles connues, puis la page de connexion, puis les couches qui rattrapent ce qui est passé. Chaque étape indique exactement où cliquer, et six d’entre elles montrent une capture de l’écran que vous devez obtenir. Les exemples utilisent WordPress et un panneau d’hébergement classique, mais les mêmes réglages existent sous d’autres noms sur PrestaShop, Joomla, Drupal, Shopify et les sites sur mesure.

Ce qu’il faut vraiment pour bloquer les hackers

Aucun réglage unique ne rend un site sûr. Les attaquants suivent une séquence — trouver le site, trouver une faiblesse, entrer, rester, exploiter — et chaque étape ci-dessous supprime un maillon de cette chaîne. Le pare-feu arrête le balayage de masse. Les mises à jour suppriment la faiblesse que le scanner cherchait. L’authentification à deux facteurs rend un mot de passe volé inutile. La surveillance fait que, si tout le reste échoue, vous l’apprenez en quelques minutes plutôt que par un client.

L’objectif n’est pas un système impénétrable : c’est d’être assez coûteux pour qu’une campagne automatisée abandonne et passe à la cible suivante. Presque tous les sites piratés que nous nettoyons tournaient avec une extension obsolète, un mot de passe réutilisé, ou les deux. Corrigez cela et vous vous écartez déjà de l’immense majorité de la menace — et aucune des 10 étapes ne demande un développeur ni ne coûte plus que votre hébergement actuel.

Avant de commencer

• Un accès administrateur à votre CMS, et vos identifiants du panneau d’hébergement — plusieurs étapes se passent sur le serveur, pas dans WordPress.
• L’accès aux DNS du domaine, si vous faites passer le trafic par un pare-feu cloud à l’étape 1.
• Un gestionnaire de mots de passe pour conserver les identifiants, codes de secours et clés d’API que vous allez créer.
• Environ deux heures, idéalement en dehors des heures d’ouverture — et une sauvegarde fraîche avant toute modification.

Un avertissement avant la première étape : si votre site est déjà compromis, le durcir maintenant ne fait qu’enfermer l’intrus à l’intérieur. Nettoyez d’abord, puis revenez ici.

Étape 1 — Placez un pare-feu devant votre site

Un pare-feu applicatif (WAF) inspecte chaque requête avant qu’elle n’atteigne votre serveur et rejette celles qui correspondent à des schémas d’attaque connus : injection SQL, cross-site scripting, téléversements malveillants, vagues de credential stuffing. C’est l’heure la plus rentable de ce guide, car il protège même les failles que vous n’avez pas encore corrigées.

Deux options. Un WAF cloud — Cloudflare et Sucuri proposent des offres adaptées, l’offre gratuite de Cloudflare comprise — filtre le trafic avant qu’il ne touche votre hébergeur : vous pointez les serveurs de noms du domaine vers le fournisseur et activez le jeu de règles managé. Un WAF en extension comme Wordfence s’exécute à l’intérieur de WordPress : bien plus simple à activer, mais il ne voit que les requêtes déjà arrivées sur votre serveur. Si vous encaissez des paiements, choisissez l’option cloud.

Terminez en fermant la porte de service : une fois le trafic passé par le proxy, demandez à votre hébergeur de refuser les connexions arrivant directement sur l’IP du serveur. Sinon, un attaquant qui découvre votre adresse d’origine contourne simplement le pare-feu. Surveillez ensuite les événements pendant quelques jours avant de durcir une règle : des réglages trop agressifs bloquent des clients, et un client bloqué est une commande perdue.

Étape 2 — Mettez tout à jour, puis supprimez l’inutile

Les logiciels obsolètes sont de loin la première cause de compromission. Quand une faille d’extension est divulguée, le code d’exploitation est généralement public en quelques jours et les scanners cherchent les installations non corrigées en quelques heures. Le correctif attend presque toujours déjà dans votre tableau de bord.

Allez dans Tableau de bord → Mises à jour, appliquez tout ce qui est en attente, puis ouvrez Extensions et activez les mises à jour automatiques pour chaque extension et votre thème. WordPress installe seul ses versions mineures et de sécurité : laissez cela actif. Faites ensuite ce que presque tout le monde saute : supprimez toutes les extensions et thèmes que vous n’utilisez pas, ainsi que ceux dont le développeur a cessé la maintenance. Désactivé ne veut pas dire supprimé : le code reste sur le disque et reste accessible depuis le web.

Ne vous arrêtez pas au CMS. Votre panneau d’hébergement contrôle la version de PHP, et une version en fin de vie ne reçoit plus aucun correctif de sécurité, même si WordPress est parfaitement à jour. Si la vôtre est plus ancienne que les versions signalées comme supportées, planifiez la mise à niveau — testez d’abord sur une copie de préproduction, car de très vieilles extensions peuvent casser.

Étape 3 — Rendez la page de connexion indevinable

Les bots ne devinent pas les mots de passe au hasard. Ils rejouent les milliards de couples identifiant/mot de passe déjà fuités lors des brèches d’autres entreprises, en pariant que quelqu’un en a réutilisé un. Si votre mot de passe administrateur protège autre chose — votre messagerie, un autre site, un vieux forum — considérez-le comme déjà connu.

Quatre réglages, dans votre extension de sécurité ou le panneau de protection de votre hébergeur. Limitez les tentatives de connexion à environ cinq, avec un blocage d’une heure, pour qu’une attaque par force brute meure après cinq essais au lieu de durer toute la nuit. Exigez l’authentification à deux facteurs pour tout compte pouvant publier ou installer : un mot de passe volé ne vaut alors plus rien. Générez des mots de passe longs et aléatoires par compte et rangez-les dans le gestionnaire — notre guide sur la création d’un mot de passe fort explique ce qui rend un mot de passe réellement difficile à casser. Enfin, changez l’URL de connexion de /wp-login.php et désactivez XML-RPC si rien chez vous n’en a besoin : ce ne sont pas de vraies protections, mais elles vous sortent de la liste par défaut des scanners.

Imprimez ou enregistrez les codes de secours ailleurs que sur le site que vous venez de verrouiller. Ne plus pouvoir accéder à son propre panneau d’administration un dimanche est la raison la plus fréquente pour laquelle les gens désactivent la 2FA — ce qui les ramène exactement au point de départ.

Étape 4 — Forcez le HTTPS sur toutes les pages

Le HTTPS chiffre tout ce qui circule entre vos visiteurs et votre serveur : mots de passe, détails de commande, formulaires de contact. Sans lui, toute personne partageant le Wi-Fi d’un café avec votre client peut lire ce trafic, et les navigateurs affichent « Non sécurisé ». C’est aussi un critère de classement confirmé par Google : le gain est double.

Dans votre panneau d’hébergement, ouvrez SSL/TLS et émettez un certificat pour chaque domaine et sous-domaine, y compris www et tout sous-domaine boutique ou préproduction. Presque tous les hébergeurs proposent aujourd’hui des certificats gratuits et automatiques de Let’s Encrypt, généralement derrière un bouton AutoSSL. Activez la redirection HTTPS forcée, vérifiez que le renouvellement automatique est actif, et dans WordPress réglez Adresse web de WordPress et Adresse web du site sur la version https:// dans Réglages → Général. Notre guide pas à pas sur l’installation d’un certificat SSL couvre les détails propres à chaque hébergeur.

Si le cadenas n’apparaît toujours pas, vous avez du contenu mixte : une image, une police ou un script se charge encore en http://. La console de développement de votre navigateur nomme le fichier fautif. Une fois propre, demandez à votre hébergeur d’ajouter l’en-tête HSTS, qui interdit au navigateur de réessayer la version non chiffrée.

Étape 5 — Verrouillez les fichiers que visent les attaquants

Bien avant d’essayer votre page de connexion, les scanners demandent une courte liste de fichiers par leur nom : wp-config.php et .env pour les identifiants de base de données et les clés d’API, backup.zip pour une copie de tout, /wp-content/uploads/ en espérant que le listage des répertoires soit actif. Chacune de ces requêtes est gratuite pour eux et catastrophique pour vous si elle aboutit.

Dans le gestionnaire de fichiers de votre hébergeur, réglez les permissions sur 644 pour les fichiers et 755 pour les répertoires, et resserrez wp-config.php à 400 ou 440. Ne laissez jamais rien en 777. Ajoutez ensuite trois règles à .htaccess (ou l’équivalent Nginx) : refuser l’accès direct à wp-config.php et .env, désactiver le listage des répertoires avec Options -Indexes, et — la plus importante — bloquer l’exécution de PHP dans le dossier uploads, pour qu’un fichier malveillant téléversé ne puisse pas être exécuté.

Pendant que vous y êtes, supprimez ce qui n’aurait jamais dû rester sur un serveur en production : exports de base de données, info.php, anciens dossiers de thèmes et la copie site-old de la dernière refonte. Un fichier oublié est un fichier non corrigé.

Étape 6 — Absorbez les vagues avec un CDN et des limites de débit

Une attaque par déni de service distribué ne vole rien : elle rend simplement votre site indisponible, ce qui, pour une boutique en ligne, revient à être cambriolé. Les petits sites sont touchés plus souvent qu’on ne croit, parfois comme dommage collatéral d’une attaque visant un voisin sur le même hébergement mutualisé.

Si vous avez fait l’étape 1 avec un fournisseur cloud, l’essentiel est déjà en place : le CDN absorbe le trafic volumétrique sur son propre réseau. Ajoutez par-dessus des règles de limitation de débit sur les points qui vous coûtent le plus par requête : la page de connexion, la recherche, le panier et le paiement, et toute route d’API. Une règle du type « plus de 10 requêtes vers /wp-login.php depuis une IP en une minute → blocage d’une heure » supprime toute une catégorie de bruit. Avec une extension seule, activez son équivalent et demandez à votre hébergeur quelle protection amont il fournit.

Étape 7 — Soyez alerté avant vos clients

Une intrusion est rarement découverte au moment où elle a lieu. Elle l’est des semaines plus tard, quand Google signale le site, quand l’hébergeur suspend le compte pour envoi de spam, ou quand un client envoie une capture d’écran. C’est dans cet intervalle que les dégâts s’accumulent.

Activez le journal d’activité de votre extension de sécurité et réglez des alertes e-mail sur les quatre événements qui comptent vraiment : la création d’un compte administrateur, la modification d’un fichier du cœur ou d’une extension, l’installation ou l’activation d’une extension, et des échecs de connexion répétés sur un compte existant. Le reste est du bruit, et des alertes qu’on ignore valent moins que pas d’alertes du tout.

Envoyez ces alertes à une adresse réellement consultée, et décidez à l’avance qui agit sur une alerte reçue à 2 h du matin. Si une entreprise marocaine subit un incident sérieux, la réglementation marocaine en cybersécurité précise qui doit être informé et dans quel délai — mieux vaut le savoir avant d’en avoir besoin.

Étape 8 — Analysez régulièrement, pas après l’intrusion

L’analyse remplit deux rôles. Un scan de vulnérabilités vous dit lesquelles des portes ci-dessus sont encore ouvertes : en-têtes manquants, fichiers exposés, composants obsolètes. Un scan de malware compare vos fichiers aux originaux et signale tout ajout ou modification — c’est ainsi que l’on détecte une porte dérobée posée avant le début du durcissement.

Lancez notre scanner de site gratuit pour une vue extérieure de ce que voit un attaquant, et programmez chaque semaine le contrôle d’intégrité des fichiers de votre extension de sécurité. Lisez le rapport le jour même : une analyse que personne ne lit n’est qu’une tâche qui donne l’impression d’être en sécurité.

Conservez le premier résultat sain. Dans six mois, quand un fichier vous semblera étrange, le moyen le plus rapide de savoir s’il doit être là sera de le comparer à une analyse en laquelle vous aviez confiance.

Étape 9 — Gardez des sauvegardes que vous avez vraiment restaurées

Les sauvegardes n’empêchent rien. Elles font la différence entre un mauvais après-midi et une entreprise perdue, et ce sont le seul contrôle qui fonctionne encore quand toutes les autres étapes ont échoué.

Trois règles rendent une sauvegarde utile. Stockez-la en dehors du serveur qu’elle protège : une copie dans le même compte d’hébergement est chiffrée avec le reste par un rançongiciel, et supprimée avec le reste si le compte est suspendu. Conservez au moins 30 jours d’historique, car une porte dérobée posée il y a trois semaines se trouve aussi dans la sauvegarde d’hier. Et restaurez-en une sur un site de préproduction avant d’en avoir besoin, en chronométrant l’opération : une sauvegarde jamais restaurée est une hypothèse, pas un plan.

Étape 10 — Prouvez que les défenses tiennent

Neuf étapes de durcissement laissent encore une hypothèse : que tout cela fonctionne. Deux choses la testent. La moins chère, c’est votre équipe : un e-mail de phishing imitant de façon convaincante votre hébergeur, votre banque ou Google livrera un mot de passe administrateur qu’aucun pare-feu ne protège. Assurez-vous que toute personne pouvant se connecter sait repérer un e-mail de phishing, utilise un compte par personne, et ne se connecte jamais à l’administration depuis un Wi-Fi public sans VPN.

La plus complète, c’est le test d’intrusion : une attaque simulée et autorisée, menée par des spécialistes qui enchaînent les failles que les scanners automatiques ne voient pas — une logique métier qui laisse un client lire la commande d’un autre, un site de préproduction oublié qui partage la base de production, une API qui fait confiance à un paramètre qu’elle devrait vérifier. Le résultat n’est pas une liste de reproches mais un ensemble de correctifs précis et hiérarchisés. Pour un site qui encaisse des paiements ou détient des données clients, c’est la différence entre espérer être sécurisé et le savoir.

Vérifiez votre travail — un contrôle en cinq minutes

Ne supposez pas qu’un réglage a pris effet parce que vous l’avez enregistré. Parcourez cette liste avant de fermer l’ordinateur :

• Tapez votre adresse en http://. Elle doit rediriger vers https:// et afficher un cadenas — sur la page d’accueil et sur une page profonde.
• Saisissez cinq fois un mauvais mot de passe depuis une fenêtre de navigation privée. Vous devez être bloqué, pas invité à un sixième essai.
• Déconnectez-vous puis reconnectez-vous. On doit vous demander votre mot de passe et un code de votre application d’authentification.
• Demandez votresite.ma/wp-config.php et votresite.ma/wp-content/uploads/ dans un navigateur. Les deux doivent être refusés, pas affichés.
• Ouvrez Utilisateurs. Chaque compte doit appartenir à quelqu’un que vous pouvez nommer aujourd’hui.
• Ouvrez votre stockage de sauvegardes et vérifiez que le fichier d’hier est présent et pas anormalement petit.

Programmez-le une fois par mois, en complément de notre guide plus complet pour sécuriser mon site web.

Questions fréquentes

Combien de temps faut-il pour bloquer les hackers d’un site de petite entreprise ?

Les étapes 1 à 5 représentent un après-midi de travail et éliminent la grande majorité des attaques automatisées. Les étapes 6 à 10 sont des habitudes plutôt que des tâches : un rapport d’analyse à lire chaque semaine, un contrôle mensuel de cinq minutes, des alertes qui arrivent dans une vraie boîte mail, et des mises à jour qui s’installent désormais seules.

Faut-il payer pour un pare-feu ou une extension de sécurité ?

Non. Les offres gratuites des principaux pare-feu cloud et les versions gratuites des grandes extensions de sécurité couvrent toutes les étapes de ce guide. Les offres payantes apportent surtout des signatures de malware mises à jour plus vite, un support prioritaire et un service de nettoyage en cas de compromission — utile pour un site qui encaisse des paiements, optionnel sinon.

Mon site n’est pas sous WordPress. Ces étapes s’appliquent-elles quand même ?

Oui — seuls les noms des menus changent. Pare-feu, mises à jour, identifiants forts avec 2FA, fichiers verrouillés, limitation de débit, alertes, analyses et sauvegardes testées s’appliquent aussi bien à PrestaShop, Joomla, Drupal, Shopify et aux applications sur mesure. Sur une plateforme hébergée comme Shopify, l’éditeur gère les mises à jour et le durcissement du serveur, ce qui vous retire les étapes 2 et 5 et rend les étapes 3 et 10 encore plus importantes.

Comment savoir si des hackers sont déjà entrés ?

Les signes habituels sont des comptes administrateur que vous n’avez pas créés, des pages ou redirections apparaissant dans Google sans avoir été publiées, des fichiers modifiés à des heures inhabituelles, une hausse soudaine des e-mails sortants, ou la suspension de votre compte par l’hébergeur. Lancez une analyse de malware, vérifiez Utilisateurs, et si quelque chose se confirme, nettoyez avant de durcir.

Bloquer les hackers : l’essentiel

Les attaquants sont des opportunistes qui travaillent à grande échelle. Ils ne cherchent pas à entrer dans votre site : ils cherchent à entrer dans dix mille sites à la fois et à garder ceux qui s’ouvrent facilement. Chaque étape ci-dessus augmente ce que votre site leur coûte, et il y a toujours une cible plus facile une ligne plus bas.

Si vous ne faites que trois choses cette semaine : placez un pare-feu devant le site (étape 1), mettez tout à jour et supprimez l’inutile (étape 2), et exigez l’authentification à deux facteurs sur chaque compte administrateur (étape 3). Programmez ensuite le rappel pour le contrôle de cinq minutes — la sécurité s’entretient, elle ne s’installe pas.

Vous voulez savoir où vous en êtes avant de commencer ? SecureWeb propose une analyse de sécurité gratuite et des audits complets pour les entreprises marocaines — un moyen rapide de voir lesquelles de ces 10 étapes manquent aujourd’hui à votre site.