Qu'est-ce qu'une liste de blocage ?

Une liste de blocage est l'un des outils les plus courants en matière de cybersécurité. Elle permet aux entreprises d'arrêter le mauvais trafic connu avant qu'il n'atteigne les systèmes sensibles. Pour les sites web, les flux de connexion, les API et l'infrastructure de messagerie, les listes de blocage font souvent partie de la première couche de sécurité. Elles peuvent être utilisées pour bloquer les adresses IP, les domaines, les URL, les expéditeurs de courrier électronique, les hachages de fichiers ou d'autres indicateurs liés à des abus.

Cela semble simple, mais le sujet est plus nuancé. Une liste de blocage peut réduire le bruit, le trafic de robots, les tentatives de fraude et les attaques répétées. Elle peut également bloquer des utilisateurs légitimes par erreur, passer à côté de nouvelles menaces et, lorsqu'elle est utilisée seule, avoir du mal à lutter contre des réseaux de zombies qui évoluent rapidement. Le Centre national de cybersécurité du Royaume-Uni le dit clairement : les listes de refus aident à contrôler l'accès, mais elles n'arrêtent que les menaces qui sont déjà connues et répertoriées. Les attaquants peuvent toujours passer s'ils utilisent une infrastructure qui n'a pas encore été exclue.

Pour les exploitants de sites web, les responsables informatiques et les décideurs commerciaux, la vraie question n'est pas de savoir si les listes de blocage sont utiles. Il s'agit de savoir comment les utiliser correctement, où elles sont le plus utiles et où elles ont besoin d'être soutenues par des contrôles plus rigoureux.



Une liste de blocage est une liste d'entités dont l'accès est refusé, qui sont signalées ou filtrées parce qu'elles sont considérées comme nuisibles ou non fiables. Dans le domaine de la cybersécurité, ces entités sont souvent des adresses IP, des domaines, des URL, des sources de courrier électronique, des numéros de systèmes autonomes ou des empreintes digitales d'appareils.

En pratique, une liste de blocage fonctionne comme une règle de refus. Lorsque le trafic entrant correspond à une entrée de la liste, le système le bloque, le conteste ou le traite différemment. La documentation actuelle de Cloudflare décrit les règles d'accès IP exactement de cette manière : les organisations peuvent bloquer, autoriser ou contester le trafic sur la base d'une adresse IP, d'un ASN ou d'un pays.


Une liste de blocage fonctionne en comparant l'activité entrante avec les mauvaises entrées connues. La vérification a généralement lieu à la périphérie du système, avant que la demande n'atteigne l'application elle-même. Il peut s'agir d'un pare-feu, d'un WAF, d'une passerelle de messagerie, d'un filtre DNS, d'une passerelle API ou d'une politique de sécurité dans le nuage.

Si la source correspond à la liste, le système peut réagir de différentes manières. Il peut bloquer purement et simplement la demande. Il peut la contester, par exemple à l'aide d'un CAPTCHA. Enfin, il peut marquer la demande pour une inspection plus approfondie. La documentation de Cloudflare reflète ce modèle opérationnel en prenant en charge les actions de blocage, d'autorisation et de contestation pour les règles d'accès basées sur l'IP.

Certaines listes de blocage sont statiques et mises à jour manuellement. D'autres sont dynamiques et alimentées par des renseignements sur les menaces. Google Cloud présente cette approche plus moderne dans Cloud Armor, où le trafic peut être autorisé ou bloqué sur la base de catégories de renseignements sur les menaces et de listes d'adresses IP nommées.


Toutes les listes de blocage ne font pas le même travail.

Un Liste de blocage IP bloque le trafic provenant d'adresses ou de plages d'adresses IP hostiles connues. Cette méthode est souvent utilisée pour les attaques par force brute, le scraping, le credential stuffing et les abus répétés provenant de la même source.

Une liste de blocage de domaines bloque les domaines malveillants ou de mauvaise réputation connus. Spamhaus décrit sa Liste de blocage des domaines comme une liste de domaines ayant une mauvaise réputation, tenue à jour grâce à de multiples signaux de réputation.

Une liste de blocage DNS empêche la résolution de mauvaises destinations connues. Cloudflare documente ceci comme un modèle de politique DNS commun pour bloquer les domaines ou les IP malveillants par le biais de listes de blocage.

Il existe également des listes de blocage de courrier électronique, des listes de blocage d'URL et des listes de refus au niveau de l'application. Le type exact est important car le modèle de menace change. Une liste de blocage de domaine est utile contre les destinations malveillantes. Une liste de blocage d'adresses IP est utile contre les sources hostiles. Un site web attaqué par un robot a souvent besoin des deux.


Une liste de blocage et une liste d'autorisation résolvent des problèmes différents.

Une liste de blocage ne bloque que ce qui est connu et explicitement refusé.
Une liste d'autorisations n'autorise que ce qui est fiable et explicitement approuvé.

Cette distinction est importante car les listes d'autorisation sont souvent plus fortes dans les environnements où la confiance est élevée. Les NCSC indique que si vous souhaitez respecter le principe du moindre privilège, vous devez utiliser des listes d'autorisation. Il prévient également que les listes de refus ont des limites importantes car elles ne peuvent arrêter que ce qui est déjà connu et inclus.

Cela ne signifie pas que les listes de blocage sont faibles. Cela signifie qu'elles sont mieux utilisées lorsqu'un large accès public doit rester possible, comme les sites web, les connexions des clients, les portails d'assistance et les API publiques. Dans ces environnements, il est impossible d'établir une liste d'autorisation pour chaque visiteur légitime. Les listes de blocage sont donc utiles, mais elles ont besoin d'être aidées par des mécanismes de limitation de débit, de détection des anomalies, d'analyse comportementale et de contestation.


Les listes de blocage sont importantes parce qu'elles réduisent la charge évitable et arrêtent rapidement les abus répétés. Si votre site est touché par des robots de scraping, des tentatives de connexion répétées, des soumissions de spam ou des adresses IP connues comme mauvaises, le fait de les bloquer à la périphérie permet d'économiser du temps de traitement, de réduire le volume des journaux et d'alléger le travail de l'assistance.

Ils contribuent également à réduire la surface d'attaque. Une équipe de sécurité n'a pas besoin que toutes les menaces connues soient sophistiquées. Elle a besoin que de nombreuses attaques de faible valeur échouent rapidement et à peu de frais. Une liste de blocage convient parfaitement à cet effet.

Ceci est particulièrement important pour les services publics. La documentation de Google Cloud sur la sécurité montre comment les défenses actuelles des entreprises utilisent des listes d'adresses IP et des renseignements sur les menaces pour filtrer le trafic avant qu'il n'atteigne les applications protégées.

Pour les chefs d'entreprise, la valeur est pratique. Moins de trafic indésirable signifie moins de ressources gaspillées. Moins d'attaques répétées signifie une meilleure visibilité des menaces réelles. Un meilleur filtrage à la périphérie améliore également la résilience lorsque le site est confronté à des vagues d'abus automatisés.


Les entités sont généralement placées sur une liste de blocage en raison d'abus répétés, et non par accident.

Les adresses IP peuvent être bloquées en raison d'attaques par force brute, de credential stuffing, de spam, de scraping, de scanning ou de participation à des botnets. Spamhaus indique que sa liste de blocage basée sur les IP inclut des IP liées au spam, à l'hébergement malveillant, à l'espace IP détourné ou à d'autres activités adverses.

Les équipes de sécurité bloquent les domaines lorsqu'ils hébergent des pages d'hameçonnage, des logiciels malveillants, des redirections abusives ou du contenu de mauvaise réputation. Elles bloquent les URL lorsque les attaquants les utilisent dans des chaînes d'attaque. Elles bloquent également les sources de courrier électronique qui envoient des spams ou soutiennent des activités frauduleuses.

Une entreprise peut également créer ses propres listes de blocage internes. Par exemple, si un ASN, un pays ou un client API abuse de façon répétée d'un point de connexion, l'entreprise peut choisir de bloquer ou de contester ce trafic localement.


Les listes de blocage sont utiles, mais elles ne suffisent pas à elles seules.

Leur principale limite est qu'elles sont réactives. Une liste de blocage n'arrête que ce qui est déjà connu. Le NCSC insiste sur ce point : les listes de refus ont des limites importantes car les attaquants peuvent utiliser une infrastructure qui n'est pas encore répertoriée.

Les faux positifs constituent un autre problème. Une IP partagée peut véhiculer à la fois des utilisateurs légitimes et un trafic abusif. Le blocage de l'ensemble de l'IP peut perturber les clients, les partenaires ou les réseaux de bureau. La réaffectation dynamique des adresses IP pose un autre problème. Un nouvel utilisateur peut hériter d'une IP ayant un mauvais historique.

Il y a aussi le problème du contournement. L'ENISA note dans son rapport sur la sécurité des résolveurs DNS que les listes de blocage et le blocage de type RPZ peuvent être contournés, par exemple lorsque les attaquants utilisent les adresses IP directement sans résolution DNS, de sorte que les listes de blocage ne peuvent pas être considérées comme une défense complète.

C'est pourquoi les équipes matures ne se demandent pas si une liste de blocage fonctionne. Elles se demandent ce qu'elle peut arrêter de manière réaliste, à quelle vitesse elle est mise à jour et ce qui doit se passer lorsque la confiance est élevée, moyenne ou faible.


Un cas d'utilisation simple et courant est celui d'une page de connexion faisant l'objet d'une attaque par saturation des données d'identification. Les équipes de sécurité peuvent bloquer ou contester les adresses IP abusives répétées, mais toutes les sources suspectes ne sont pas connues à l'avance. Dans ce cas, les contrôles basés sur les défis permettent de combler cette lacune.

Le filtrage DNS est un autre cas d'utilisation. Si une entreprise souhaite empêcher les utilisateurs ou les systèmes d'accéder à des domaines malveillants connus, une liste de blocage DNS peut arrêter la résolution avant que la connexion ne soit établie.

Un troisième cas d'utilisation est la protection des applications en périphérie. Cloudflare et Google documentent tous deux des politiques de trafic modernes qui combinent des listes de blocage avec une logique de filtrage plus large telle que la géolocalisation, les règles basées sur l'ASN et les catégories de renseignements sur les menaces.

Pour les sites web, c'est là que le CAPTCHA devient pertinent. Une liste de blocage est excellente lorsque la source est déjà connue comme mauvaise. Un CAPTCHA est utile lorsque la source est suspecte mais pas encore assez certaine pour la bloquer en toute sécurité. Pour les organisations européennes, captcha.eu correspond bien à cette couche intermédiaire. Il offre aux opérateurs de sites web un moyen conforme à la GDPR de distinguer le trafic humain des abus automatisés sans s'appuyer uniquement sur des règles de refus statiques.


La première règle consiste à ne pas considérer une liste de blocage comme une stratégie complète. Il s'agit d'une couche.

La deuxième règle consiste à utiliser des données fiables et actuelles. Une liste périmée crée des angles morts. Une liste de mauvaise qualité crée des faux positifs. Les listes fondées sur le renseignement sur les menaces sont généralement meilleures que les listes manuelles ad hoc, bien que les listes internes personnalisées soient toujours utiles en cas d'abus locaux répétés.

La troisième règle consiste à combiner les listes de blocage avec les listes d'autorisation et la logique de contestation, le cas échéant. Le modèle de règles d'accès de Cloudflare reflète ce principe en prenant en charge les actions de blocage, d'autorisation et de contestation plutôt que le refus pur et simple.

La quatrième règle consiste à examiner les résultats. Si le trafic légitime est bloqué trop souvent, la liste ou la politique doit être affinée. Une configuration solide ne se contente pas de bloquer avec précision. Elle est également gérable sur le plan opérationnel.


Les listes de blocage ne disparaissent pas, mais elles évoluent. Les listes statiques seules sont moins efficaces contre les réseaux de zombies, les proxies résidentiels, les infrastructures tournantes et les campagnes de fraude qui répartissent l'activité entre de nombreuses sources.

C'est pourquoi les défenses modernes s'appuient de plus en plus sur la réputation, les signaux comportementaux et les politiques adaptatives plutôt que sur un simple refus statique. Le modèle actuel de veille sur les menaces de Google Cloud reflète cette évolution en permettant aux entreprises d'appliquer des règles basées sur des catégories de renseignements sélectionnées, et pas seulement sur des adresses IP saisies manuellement.

L'orientation stratégique est claire. Les listes de blocage restent importantes, mais surtout dans le cadre d'un modèle de confiance plus large. L'avenir ne consiste pas à “bloquer tout ce qui est mauvais”. Il s'agit de “marquer, filtrer, remettre en question et répondre en fonction de la confiance et du contexte”.”


Une liste de blocage est un outil pratique permettant d'interdire l'accès aux mauvaises sources connues. Elle aide les entreprises à réduire le trafic abusif, à protéger les systèmes publics et à économiser les ressources. Elle est particulièrement utile contre les récidivistes, les domaines de mauvaise réputation et les infrastructures malveillantes bien connues.

Mais une liste de blocage n'est pas une stratégie de sécurité complète. Elle peut passer à côté de nouvelles menaces, créer des faux positifs et se heurter à des abus distribués ou en évolution rapide. La meilleure approche est celle des couches. Utilisez des listes de blocage pour le mauvais trafic connu, des listes d'autorisation lorsque la confiance est étroitement définie et des contrôles basés sur les défis lorsque la certitude est moindre. Dans ce modèle, un CAPTCHA axé sur la protection de la vie privée tels que captcha.eu peuvent ajouter une étape de vérification importante entre “mauvais connu” et “vraisemblablement humain”.”


Qu'est-ce qu'une liste de blocage en matière de cybersécurité ?

Une liste de blocage est une liste d'adresses IP, de domaines, d'URL, de sources de courrier électronique ou d'autres identifiants dont l'accès est refusé parce qu'ils sont liés à des activités malveillantes ou non fiables.

Quelle est la différence entre une liste de blocage et une liste d'autorisation ?

Une liste de blocage bloque les entités connues comme mauvaises. Une liste d'autorisation n'autorise que les entités de confiance connues. Les listes d'autorisation sont généralement plus robustes dans les environnements où les privilèges sont moindres, tandis que les listes de blocage sont plus pratiques pour les services publics.

Une liste de blocage des adresses IP est-elle suffisante pour arrêter les robots ?

Non. Cela permet de lutter contre les mauvaises adresses IP connues, mais les attaquants peuvent changer d'infrastructure, utiliser des adresses IP partagées ou se tourner vers de nouvelles sources. C'est pourquoi les listes de blocage doivent être associées à une limitation du débit, à des contrôles de comportement et à des mécanismes de contestation.

Pourquoi les utilisateurs légitimes sont-ils parfois bloqués ?

En effet, plusieurs utilisateurs peuvent partager la même adresse IP, ou une adresse peut avoir une mauvaise réputation en raison d'abus antérieurs. Les faux positifs sont une limite normale des contrôles basés sur des listes de blocage.

Les CAPTCHA peuvent-ils remplacer une liste de blocage ?

Une liste de blocage et un CAPTCHA résolvent des problèmes différents. Une liste de blocage bloque les mauvaises sources connues. Un CAPTCHA permet de vérifier le trafic suspect lorsqu'une source n'est pas encore suffisamment sûre pour être bloquée d'emblée.

fr_FRFrench