Dans l’architecture de WordPress, plusieurs fichiers peu connus du grand public jouent un rôle historique dans les échanges entre sites web. C’est le cas de wp-trackback.php, un fichier que l’on trouve encore aujourd’hui dans toutes les installations WordPress, mais dont la fonction soulève des questions : à quoi sert-il exactement ? Est-il encore utile en 2025 ? Représente-t-il un risque pour la sécurité ? Cet article vous plonge dans les rouages techniques et historiques du fichier wp-trackback.php, en évaluant sa pertinence actuelle, ses usages potentiels et les bonnes pratiques à adopter pour sécuriser son site WordPress.

Les origines et le rôle du fichier wp-trackback.php

Le fichier wp-trackback.php fait partie des composants historiques de WordPress, introduit dès les premières versions du CMS, au début des années 2000. Pour comprendre sa raison d’être, il faut remonter à une époque où le web était principalement constitué de blogs indépendants, reliés entre eux par des liens manuels et des références croisées. C’était l’ère des blogs personnels, bien avant l’avènement des réseaux sociaux. Les trackbacks sont une technologie issue de la plateforme Movable Type, inventée par Six Apart en 2002. WordPress, qui a vu le jour en 2003 avec sa version 0.7, a adopté ce système dans sa version 1.0 (janvier 2004), dans le but d’intégrer une forme de communication entre sites web : lorsque l’auteur d’un article cite un autre billet publié ailleurs, une notification peut être automatiquement envoyée à l’auteur de l’article cité. Celui-ci peut alors approuver (ou non) l’affichage d’un lien retour accompagné d’un extrait du texte d’origine dans la section des commentaires de son propre article.

Le fonctionnement repose sur un échange entre serveurs : lorsqu’un site A rédige un article qui fait référence à un billet du site B, il envoie une requête HTTP POST à l’adresse https://siteB.com/wp-trackback.php?p=ID, où ID représente l’identifiant unique de l’article cible. Le fichier wp-trackback.php traite alors cette requête et, s’il la valide, ajoute un commentaire spécial sous l’article concerné. Ce commentaire contient généralement :

• title : le titre de l’article d’origine (celui du site A)
• url : l’URL exacte du lien vers l’article source
• excerpt : un court extrait du contenu
• blog_name : le nom du blog ayant envoyé le trackback

Ce mécanisme permettait de construire un maillage interblog riche, presque conversationnel, sans intervention humaine. Les trackbacks étaient ainsi vus comme un moyen d’annotation croisée, équivalent à un commentaire initié par un auteur tiers. L’intérêt de ce système résidait dans sa capacité à générer du trafic réciproque, à enrichir le contenu via des sources connexes, et à renforcer l’autorité éditoriale entre publications liées thématiquement. Le fichier wp-trackback.php agit donc comme une interface serveur spécifique aux trackbacks. Contrairement aux pingbacks (qui utilisent xmlrpc.php), le trackback est basé sur un protocole simple, sans vérification de lien. Cela signifie qu’aucune validation technique n’est effectuée pour s’assurer que le site A contient bien un lien vers le site B : WordPress se contente de recevoir la requête et d’enregistrer les données fournies, ce qui a eu des conséquences importantes sur la sécurité (nous y reviendrons plus loin).

Dans le cœur de WordPress, wp-trackback.php remplit donc plusieurs rôles techniques :

• Identifier l’article cible via son ID (paramètre ?p=123)
• Accepter une requête POST contenant les champs title, url, excerpt et blog_name
• Vérifier si les trackbacks sont autorisés pour l’article en question
• Insérer une entrée spéciale dans la base de données des commentaires (type « trackback »)
• Afficher, si activé, le trackback comme commentaire visible à l’écran

Dès WordPress 2.0 (sorti en décembre 2005), les pingbacks ont commencé à supplanter les trackbacks, car ils permettent une vérification plus fiable (ils testent que le lien est effectivement présent sur la page source). Néanmoins, wp-trackback.php est resté présent dans toutes les versions de WordPress, y compris la version 6.8 publiée en avril 2025. Son maintien dans le noyau repose principalement sur des raisons de rétrocompatibilité, bien qu’il soit désactivé par défaut sur les nouveaux articles depuis WordPress 4.7 (décembre 2016).

Le fichier wp-trackback.php est ainsi un vestige d’un web plus collaboratif et moins centralisé, où les blogs communiquaient entre eux par des mécanismes automatiques. Si son usage a presque disparu, il reste une porte d’entrée technique encore activée sur de nombreux sites WordPress — et donc un vecteur potentiel de spam ou d’abus, d’autant plus que la majorité des webmasters ignorent son existence.

Une analyse du fonctionnement interne du fichier wp-trackback.php

Le fichier wp-trackback.php constitue le point d’entrée des notifications de type trackback dans WordPress. Il est conçu pour recevoir des requêtes HTTP POST provenant d’autres sites, les valider, et enregistrer un commentaire de type trackback lié à l’article ciblé. Voici une analyse technique détaillée de son fonctionnement.

1. Le chargement de l’environnement WordPress

if ( empty( $wp ) ) {
    require_once __DIR__ . '/wp-load.php';
    wp( array( 'tb' => '1' ) );
}

Si la variable globale $wp (instance principale du cœur de WordPress) n’est pas définie, le fichier charge manuellement l’environnement WordPress via wp-load.php, puis initialise une requête personnalisée avec le paramètre tb=1 pour indiquer qu’il s’agit d’un trackback.

2. L’exécution en tant qu’utilisateur anonyme

wp_set_current_user( 0 );

Le traitement est toujours effectué sans authentification : l’utilisateur courant est défini à 0 (anonyme). Cela reflète le fait que les trackbacks ne nécessitent pas de connexion utilisateur, ce qui est l’une des raisons de leur vulnérabilité.

3. La définition d’une fonction de réponse XML

function trackback_response( $error = 0, $error_message = '' ) { ... }

Cette fonction retourne une réponse au format XML. Elle est utilisée pour indiquer au client distant si le trackback a été accepté (<error>0</error>) ou rejeté (<error>1</error>, avec un message explicatif). Elle est appelée à plusieurs endroits selon les cas d’échec ou de réussite du processus.

4. L’extraction de l’identifiant de l’article cible

if ( ! isset( $_GET['tb_id'] ) || ! $_GET['tb_id'] ) {
    $post_id = explode( '/', $_SERVER['REQUEST_URI'] );
    $post_id = (int) $post_id[ count( $post_id ) - 1 ];
}

Si aucun identifiant explicite n’est fourni via ?tb_id=, le script tente d’extraire l’ID de l’article ciblé à partir de l’URL. C’est une méthode heuristique qui n’est pas très robuste, mais qui vise à maintenir la compatibilité avec différents formats d’URL.

5. La récupération des données POST du trackback

$trackback_url = $_POST['url'] ?? '';
$charset       = $_POST['charset'] ?? '';
$title         = wp_unslash( $_POST['title'] ?? '' );
$excerpt       = wp_unslash( $_POST['excerpt'] ?? '' );
$blog_name     = wp_unslash( $_POST['blog_name'] ?? '' );

Le script extrait les champs attendus d’un trackback : l’URL source, le jeu de caractères, le titre, l’extrait du contenu, et le nom du blog émetteur. Les fonctions wp_unslash() sont utilisées pour retirer les antislashs ajoutés automatiquement par PHP (selon la configuration de magic_quotes_gpc).

6. La détection du charset et la conversion si nécessaire

if ( $charset ) { ... }
if ( function_exists( 'mb_convert_encoding' ) ) { ... }

WordPress tente de convertir les données textuelles dans l’encodage utilisé par le site cible (défini dans blog_charset, souvent UTF-8). Si la fonction mb_convert_encoding() est disponible (extension multibyte string), elle est utilisée pour assurer une compatibilité avec les encodages asiatiques, ISO-8859-1, etc.

Le code vérifie également que l’encodage n’est pas UTF-7, un format notoirement dangereux car exploitable dans certains contextes HTML/JavaScript.

7. La validation des données et les redirections

if ( ! isset( $post_id ) || ! (int) $post_id ) {
    trackback_response( 1, __( 'I really need an ID for this to work.' ) );
}

Si l’identifiant de l’article est manquant ou invalide, le script renvoie une erreur XML. Cela garantit que le trackback est toujours associé à un contenu spécifique.

if ( empty( $title ) && empty( $trackback_url ) && empty( $blog_name ) ) {
    wp_redirect( get_permalink( $post_id ) );
    exit;
}

Si les données sont vides, WordPress considère que la requête n’est pas un trackback valide et redirige simplement vers l’article. Cela évite d’interpréter à tort des requêtes parasites comme des tentatives de trackback.

8. La vérification et l’insertion du commentaire trackback

if ( ! pings_open( $post_id ) ) {
    trackback_response( 1, __( 'Sorry, trackbacks are closed for this item.' ) );
}

Avant d’insérer un commentaire, WordPress vérifie si les pings sont autorisés pour ce post. S’ils sont désactivés (ce qui est le cas par défaut depuis WP 4.7), la requête est rejetée.

$comment_content = "<strong>$title</strong>\n\n$excerpt";
$comment_type = 'trackback';

Les données du trackback sont formatées pour constituer le contenu du commentaire à enregistrer. Le type de commentaire est défini comme trackback, ce qui le différencie des commentaires standards et des pingbacks dans la base de données.

9. La détection des doublons

$dupe = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM $wpdb->comments WHERE comment_post_ID = %d AND comment_author_url = %s",
        $comment_post_id,
        $comment_author_url
    )
);

Avant de créer le commentaire, le script vérifie s’il existe déjà un trackback provenant de la même URL pour le même article. Si c’est le cas, il refuse la requête afin d’éviter les doublons en base.

10. La création du commentaire

$commentdata = array( ... );
$result = wp_new_comment( $commentdata );

Le tableau $commentdata est transmis à la fonction wp_new_comment(), qui insère le commentaire dans la base de données, déclenche les actions WordPress (comme les notifications e-mail), et applique les filtres de modération si nécessaires.

11. Les hooks et actions WordPress

do_action( 'pre_trackback_post', ... );

do_action( 'trackback_post', $trackback_id );

Ces deux hooks permettent à des plugins ou extensions de s’interfacer au moment où un trackback est reçu (avant l’enregistrement), puis après son insertion en base. Cela offre une grande extensibilité, par exemple pour logguer l’événement, l’associer à des statistiques, ou appliquer des règles de filtrage personnalisées.

12. La réponse finale

trackback_response( 0 );

Si tout s’est bien passé, WordPress retourne un message XML indiquant le succès de l’opération. Cette réponse est lue par le site source, qui peut alors signaler à l’utilisateur que le trackback a été enregistré avec succès.

Le code de wp-trackback.php reflète l’architecture WordPress classique : Traitement des entrées, validation, interaction avec la base de données via $wpdb, et exécution de hooks. Il est conçu pour être extensible, mais il repose sur des mécanismes simples qui manquent aujourd’hui de robustesse en termes de sécurité (absence d’authentification, peu de vérification, support limité du format XML). Bien qu’il soit fonctionnel, ce fichier est resté quasiment inchangé depuis WordPress 0.71. Son architecture statique et non sécurisée explique en grande partie pourquoi son usage est déconseillé aujourd’hui.

Pourquoi wp-trackback.php est devenu obsolète

À sa création, la fonctionnalité de trackback représentait une avancée dans la manière dont les blogs pouvaient interagir entre eux de manière automatisée. Mais avec le temps, les limites techniques du système sont devenues évidentes, à mesure que les standards de sécurité, d’interopérabilité et de performance du web ont évolué. Le fichier wp-trackback.php est aujourd’hui largement considéré comme dépassé, pour plusieurs raisons techniques et structurelles.

1. Les problèmes de spam massif

Le système de trackback repose sur un envoi libre de requêtes HTTP POST vers le fichier wp-trackback.php, sans aucune authentification, ni signature numérique, ni validation de provenance. En pratique, cela signifie que n’importe quel bot peut envoyer une requête contenant une URL, un titre, un extrait et un nom de blog fictifs. WordPress, s’il n’est pas configuré pour bloquer ces requêtes, ajoutera le commentaire en base de données comme un trackback légitime.

Résultat : dès les années 2010, le fichier wp-trackback.php est devenu un vecteur de spam très populaire. Les bots exploitent cette porte d’entrée pour insérer des milliers de commentaires contenant des liens vers :

• des fermes à liens (link farms) destinées au référencement abusif ;
• des sites de phishing ou de malware, exploitant la crédibilité du blog cible ;
• des publicités illégales (produits pharmaceutiques, casinos, cryptomonnaies, etc.).

Ces attaques peuvent saturer la table wp_comments dans la base de données, encombrer l’interface d’administration, ralentir le chargement du site (lorsque les commentaires sont chargés en front-end), et consommer inutilement des ressources serveur. À l’échelle de plusieurs centaines de requêtes par heure, cela peut constituer une véritable attaque par déni de service applicatif (DoS).

Les tentatives de contournement par des plugins antispam comme Akismet ou Antispam Bee ne suffisent pas toujours, car les requêtes trackback ne passent pas par les mêmes filtres que les formulaires de commentaires standards.

2. Le manque de vérification des liens entrants

Le trackback, contrairement au pingback, ne repose sur aucune vérification réelle de la présence d’un lien sortant dans la page source. Lorsqu’un site A envoie un trackback à un site B, ce dernier se contente d’enregistrer l’information sans vérifier si le lien existe vraiment dans l’article source.

En termes techniques, le système de trackback ne fait aucune requête HTTP inverse (ou backlink lookup) vers le site émetteur. Il ne lit pas la page source pour valider l’existence du lien. Cela ouvre la porte à des pratiques abusives telles que :

• la simulation de citations pour obtenir un lien retour (sans fournir de backlink réel) ;
• la falsification des champs title ou excerpt pour manipuler l’affichage ;
• l’envoi de milliers de faux trackbacks vers différents articles pour profiter du trafic ou du référencement du site cible.

Le protocole de pingback, introduit dans WordPress 1.5 (2005) et géré via le fichier xmlrpc.php, a été conçu pour corriger cette faiblesse. Il envoie une requête HTTP vers le site émetteur pour vérifier que le lien existe bien dans le code HTML de la page. Cela permet de filtrer les trackbacks frauduleux. Toutefois, les pingbacks présentent eux aussi des vulnérabilités (notamment en matière de DDoS via amplification), mais leur structure est plus robuste.

3. L’évolution des usages et des standards

Le déclin du trackback n’est pas seulement lié à des failles de sécurité, mais aussi à une évolution profonde des pratiques sur le web. À partir des années 2010, les interactions entre créateurs de contenus se sont déplacées vers des plateformes centralisées comme Twitter, Facebook, LinkedIn ou Reddit. Ces environnements offrent une meilleure exposition, des outils de modération intégrés et une viralité supérieure. En parallèle, les systèmes de curation modernes (agrégateurs, newsletters, plateformes de recommandation) ont remplacé les échanges automatiques de liens par des approches éditoriales manuelles. Dans ce contexte, les trackbacks sont apparus comme des vestiges techniques obsolètes, peu adaptés aux nouveaux modèles de publication et de circulation des contenus.

WordPress a lui aussi intégré cette évolution dans son cycle de développement :

• Depuis WordPress 2.7 (2008), l’interface d’administration permet de désactiver les pings et trackbacks par défaut sur les nouveaux articles ;
• Depuis WordPress 4.7 (décembre 2016), cette option est désactivée par défaut sur les installations neuves ;
• Les thèmes modernes (comme ceux basés sur Gutenberg ou le Full Site Editing) n’affichent plus les trackbacks dans la section des commentaires.

De plus, les extensions populaires comme Jetpack, Yoast SEO ou Rank Math ne prennent plus en charge les trackbacks comme méthode de promotion ou d’analyse de liens. Même Google a cessé depuis longtemps de valoriser les backlinks issus de ce mécanisme dans ses algorithmes de classement.

Enfin, le fichier wp-trackback.php n’a pas évolué depuis de nombreuses versions du noyau WordPress. Il reste présent uniquement pour des raisons de compatibilité descendante, notamment pour les installations très anciennes ou les plugins hérités encore utilisés dans des contextes spécifiques (intranet, réseaux fermés, etc.).

Faut-il désactiver ou bloquer wp-trackback.php ?

La réponse est oui, dans la majorité des cas. Si vous ne gérez pas un blog interconnecté avec d’autres publications WordPress anciennes (ce qui est rare aujourd’hui), vous n’avez probablement aucune utilité réelle des trackbacks. Pire : laisser ce fichier accessible peut introduire une faille exploitable dans votre système.

Comment désactiver les trackbacks dans WordPress

Pour éviter tout traitement des trackbacks par WordPress, voici les étapes à suivre :

1. Dans l’administration, allez dans Réglages > Discussion.
2. Désactivez l’option « Autoriser les notifications de lien en provenance d’autres blogs (pings et rétroliens) sur les nouvelles publications ».
3. Enregistrez les modifications.

Cela empêchera les nouveaux articles d’accepter les trackbacks. Pour les anciens, vous pouvez désactiver les pings en masse via l’éditeur rapide dans l’administration des articles.

Bloquer l’accès au fichier wp-trackback.php via le serveur

Pour bloquer totalement les requêtes vers wp-trackback.php, vous pouvez ajouter une règle de sécurité côté serveur.

Sur Apache (fichier .htaccess)

<Files "wp-trackback.php">
    Order allow,deny
    Deny from all
</Files>

Sur Nginx

location = /wp-trackback.php {
    deny all;
    access_log off;
    log_not_found off;
}

Ces configurations bloquent tout accès HTTP au fichier, empêchant les bots de l’utiliser comme point d’entrée.

L’utilisation d’un plugin de sécurité pour la question des pings et rétroliens

Pour les administrateurs de sites WordPress qui ne souhaitent pas intervenir directement dans la configuration serveur (via .htaccess ou Nginx), l’utilisation d’un plugin de sécurité représente une alternative simple, accessible et efficace pour désactiver les trackbacks (rétroliens) ainsi que les pingbacks. Des extensions comme Wordfence Security, Sucuri Security ou iThemes Security proposent des réglages spécifiques permettant de neutraliser automatiquement l’ensemble des points d’entrée associés à ces fonctionnalités, y compris les fichiers wp-trackback.php et xmlrpc.php. Voici un aperçu de leurs possibilités :

• Wordfence : dans les paramètres avancés du pare-feu, il est possible de bloquer les accès aux fichiers sensibles (y compris wp-trackback.php). Wordfence surveille également les types de requêtes envoyées par les bots, ce qui permet d’identifier les tentatives de spam via trackbacks et pingbacks. Des règles personnalisées peuvent être définies dans le pare-feu pour interdire certains types de POST entrants vers des endpoints comme wp-trackback.php?p=.
• Sucuri : cette extension cloud-based propose une protection active contre les attaques courantes. Elle détecte les patterns associés aux trackbacks abusifs et bloque les requêtes non autorisées. Sucuri offre aussi une fonction de hardening qui permet de désactiver certains vecteurs d’attaque, y compris les services XML-RPC et trackbacks.
• iThemes Security : l’une des options disponibles permet explicitement de désactiver les pingbacks et trackbacks à l’échelle globale du site. Le plugin modifie également les permissions des fichiers sensibles et peut injecter des règles dans le fichier .htaccess pour bloquer automatiquement wp-trackback.php.

Ces plugins offrent également des avantages complémentaires :

• Un journal détaillé des requêtes bloquées, utile pour l’audit de sécurité
• Des notifications en cas de tentative d’accès récurrente
• Des tableaux de bord accessibles même aux utilisateurs non techniques
• Une compatibilité avec les hébergements mutualisés ne permettant pas de modifier les fichiers système

En optant pour une désactivation via plugin, vous vous assurez également que la modification est réversible et persistante en cas de mise à jour, sans avoir besoin de maintenir manuellement les règles côté serveur.

Faut-il supprimer wp-trackback.php ?

Bien que wp-trackback.php soit rarement utilisé aujourd’hui, il est important de comprendre pourquoi il ne faut pas supprimer ce fichier manuellement. WordPress est un système modulaire, mais certains fichiers présents dans le noyau sont attendus par des fonctions internes ou des plugins tiers. La suppression physique de wp-trackback.php peut avoir plusieurs conséquences :

• Erreur 500 ou écran blanc : certains thèmes ou plugins anciens peuvent référencer directement le fichier via des appels HTTP ou des tests de présence. Si le fichier est manquant, cela peut déclencher des erreurs fatales sur certaines pages ;
• Problèmes lors des mises à jour de WordPress : le système de mise à jour de WordPress vérifie l’intégrité des fichiers du noyau. Si un fichier comme wp-trackback.php est absent, il peut être restauré automatiquement (ce qui rendrait la suppression inefficace), ou entraîner des erreurs de vérification de version lors d’une mise à jour automatique ;
• Incompatibilité avec certains outils tiers : des outils de synchronisation (comme ManageWP), des systèmes de sauvegarde, ou certains plugins de migration peuvent effectuer des vérifications sur la présence des fichiers WordPress standards. Leur absence pourrait générer des comportements imprévus.

La meilleure pratique recommandée par la communauté WordPress est donc de bloquer l’accès au fichier via le serveur (Apache, Nginx) ou un plugin de sécurité, plutôt que de le supprimer. Cela garantit :

• La préservation de l’intégrité du noyau WordPress ;
• La compatibilité avec les outils d’audit ou de diagnostic ;
• La possibilité de réactiver la fonctionnalité en cas de besoin spécifique (par exemple sur un blog historique en réseau fermé)/

Enfin, dans une logique DevOps ou CI/CD, il est préférable d’intégrer cette neutralisation dans vos scripts de déploiement automatisé (Ansible, Docker, GitHub Actions…) afin de garantir une désactivation systématique sur tous les environnements. Vous pouvez aussi ajouter ce blocage dans vos playbooks de sécurité pour renforcer la résilience de votre infrastructure WordPress.