« La sécurité d’un serveur, c’est autant ce qui n’en sort pas que ce qui n’y entre pas. » Cette idée, moins intuitive que la protection contre les intrusions, prend tout son sens face à une extension compromise qui tenterait d’envoyer discrètement le contenu d’une base de données vers un serveur distant. C’est précisément ce que la constante WP_HTTP_BLOCK_EXTERNAL permet de neutraliser, en coupant par défaut toute requête HTTP sortante initiée par WordPress ou par ses extensions, sauf exception explicitement autorisée.
Cet article explique le fonctionnement interne de cette constante peu documentée dans les tutoriels grand public, sans traiter du pare-feu applicatif qui agit à un niveau différent, en amont des requêtes entrantes plutôt que sur les sorties.
Ce que déclenche cette constante dans le cœur de WordPress
Toutes les requêtes HTTP sortantes initiées depuis WordPress, qu’il s’agisse d’une vérification de mise à jour, d’un appel à une API tierce par une extension, ou d’une notification envoyée à un service externe, passent par la classe WP_Http et ses fonctions d’enrobage comme wp_remote_get ou wp_remote_post. En interne, avant d’exécuter la requête, WordPress vérifie si la constante WP_HTTP_BLOCK_EXTERNAL vaut true. Si c’est le cas, la requête est bloquée, sauf si le nom d’hôte de destination figure dans la liste définie par une seconde constante, WP_ACCESSIBLE_HOSTS.
define('WP_HTTP_BLOCK_EXTERNAL', true);
define('WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,downloads.wordpress.org');
Une liste blanche à séparer par des virgules
La liste des hôtes autorisés accepte des motifs simples avec caractère générique, comme *.wordpress.org, ce qui permet d’autoriser un domaine et l’ensemble de ses sous-domaines sans les énumérer un par un. En l’absence de cette liste, ou avec une liste trop restrictive, ce sont les mises à jour du cœur elles-mêmes qui cessent de fonctionner, puisqu’elles reposent sur des requêtes sortantes vers l’infrastructure officielle de WordPress.
Pourquoi ce mécanisme protège d’abord contre l’exfiltration
La plupart des mesures de sécurité classiques sur un hébergement mutualisé se concentrent sur ce qui entre : pare-feu applicatif, limitation des tentatives de connexion, filtrage des requêtes suspectes. Cette constante agit dans l’autre sens. Si une extension compromise tente de transmettre des données sensibles vers un serveur externe non autorisé, la requête sortante est bloquée avant même de quitter le serveur, quelle que soit la sophistication de l’attaque côté code. C’est une protection particulièrement pertinente sur un hébergement mutualisé où plusieurs sites, potentiellement de qualité de maintenance inégale, cohabitent sur la même infrastructure physique.
Ce qu’il faut vérifier avant d’activer ce blocage en production
Activer cette constante sans préparation casse silencieusement toute fonctionnalité qui dépend d’un appel externe légitime. Avant toute mise en production, il faut recenser précisément les services externes réellement utilisés par le site :
- Les serveurs de mise à jour officiels de WordPress, indispensables au bon fonctionnement du cœur.
- Les API des extensions de paiement ou de formulaire, chacune avec son propre nom d’hôte à ajouter à la liste blanche.
- Les services d’envoi d’e-mails transactionnels, s’ils passent par une API externe plutôt que par le serveur de messagerie local.
- Les vérifications de licence de thèmes ou d’extensions premium, souvent hébergées sur un domaine distinct de celui de l’éditeur principal.
Diagnostiquer un blocage inattendu après activation
Si une fonctionnalité cesse de fonctionner après l’activation de cette constante, le diagnostic passe par l’ajout temporaire d’un filtre qui journalise chaque tentative de requête sortante bloquée, avant de décider de l’ajouter ou non à la liste blanche :
add_filter('pre_http_request', function ($response, $args, $url) {
error_log('Requête sortante potentiellement bloquée vers : ' . $url);
return $response;
}, 10, 3);
Cette approche, plus rigoureuse qu’un ajout systématique de domaines à la liste blanche par précaution, garantit que seuls les hôtes réellement nécessaires au fonctionnement du site obtiennent une autorisation.
| Constante | Rôle |
|---|---|
| WP_HTTP_BLOCK_EXTERNAL | Active le blocage global des requêtes sortantes |
| WP_ACCESSIBLE_HOSTS | Définit la liste blanche des hôtes autorisés malgré le blocage |
Une règle que nous appliquons sur les hébergements les plus sensibles : ne jamais activer ce blocage un vendredi après-midi, toujours au début d’une semaine, pour disposer du temps nécessaire à corriger d’éventuels effets de bord avant qu’ils ne s’accumulent.
En résumé
La constante WP_HTTP_BLOCK_EXTERNAL n’agit pas comme un pare-feu au sens classique du terme, elle inverse la logique habituelle en bloquant par défaut toute sortie non explicitement autorisée. Correctement configurée avec une liste blanche précise, elle constitue une protection sérieuse contre l’exfiltration de données sur un serveur mutualisé, à condition d’avoir préalablement recensé chaque service externe réellement nécessaire au fonctionnement du site.
