Aller au contenu

L’API REST de WordPress liste publiquement les extensions qu’elle utilise

Avertissement Tout le domaine Sécurité

Instructions générales. Ouvrez cet article depuis votre rapport PageCheck pour le voir rempli avec les extensions que l’index de votre site nomme et celles que les navigateurs de vos visiteurs utilisent.

De quoi s’agit-il

L’API REST de WordPress permet aux scripts de lire et de modifier le site via des adresses sous /wp-json/ : l’éditeur de blocs, les applications et de nombreuses extensions l’utilisent. Son index liste chaque « espace de noms » que le site enregistre — un groupe d’adresses — et WordPress lui-même n’en possède qu’une poignée. Tout autre espace de noms appartient à une extension.

Ce qui ne va pas

L’index répond à quiconque le demande, et ses espaces de noms nomment les extensions du site. Avec cette liste, un attaquant ne devine pas : la version de chaque extension est ensuite lue dans ses propres fichiers, puis comparée aux listes publiques de failles de sécurité connues. La page elle-même ne révèle que les extensions qui y chargent des fichiers ; l’index nomme aussi celles qui n’en chargent pas — extensions de SEO, de formulaires, de sauvegarde, de sécurité et d’administration.

Comment corriger

L’API reste ; seuls sa carte et les parties que les visiteurs n’appellent jamais sont masquées à quiconque n’est pas connecté comme membre de l’équipe. Les adresses masquées doivent répondre « introuvable » (404), et non « non autorisé » (401) : un 401 confirme encore que l’extension est là.

1. Trouvez quels espaces de noms vos pages appellent. Ouvrez le site dans une fenêtre de navigation privée, ouvrez les outils de développement du navigateur (F12) → Réseau, filtrez sur wp-json et utilisez le site comme un visiteur : envoyez un formulaire, ajoutez quelque chose au panier, ouvrez la page de paiement, lancez une recherche. Chaque requête listée nomme un espace de noms à conserver.

Les plus courants :

  • Contact Form 7 envoie ses formulaires via l’API REST.
  • Le panier, la page de paiement et le mini-panier en blocs de WooCommerce lisent la Store API (wc/store).
  • Les compteurs de vues comme WP Statistics et WordPress Popular Posts enregistrent les visites par son intermédiaire.
  • Les extensions de communauté, de dons et de consentement (BuddyPress, GiveWP, Complianz) l’utilisent sur les pages.

2. Masquez le reste aux visiteurs. Enregistrez ceci sous wp-content/mu-plugins/hide-rest-map.php (le dossier doit peut-être être créé ; les fichiers qui s’y trouvent sont toujours actifs). Mettez dans la liste les espaces de noms de l’étape 1 — chacun est conservé avec tout ce qu’il contient.

wp-content/mu-plugins/hide-rest-map.php

<?php
/* Hide the REST API's map from visitors who are not logged in. */
add_filter( 'rest_endpoints', function ( $endpoints ) {
	if ( current_user_can( 'edit_posts' ) ) {
		return $endpoints; // staff keep everything
	}
	// Namespaces your pages call. Everything else answers 404 to visitors.
	$keep = array( 'wc/store', 'contact-form-7/v1' );
	foreach ( array_keys( $endpoints ) as $route ) {
		$kept = false;
		foreach ( $keep as $namespace ) {
			if ( 0 === strpos( $route, '/' . $namespace . '/' ) ) {
				$kept = true;
				break;
			}
		}
		if ( ! $kept ) {
			unset( $endpoints[ $route ] );
		}
	}
	return $endpoints;
}, 5 );

// No pointer to the API in the pages' head and headers.
remove_action( 'wp_head', 'rest_output_link_wp_head' );
remove_action( 'template_redirect', 'rest_output_link_header', 11 );

Quiconque peut modifier le contenu garde toute l’API : l’éditeur de blocs, les écrans d’administration de WooCommerce et des autres extensions et Santé du site fonctionnent comme avant. Les extensions de sécurité proposent la même chose sous forme de réglage (« Désactiver l’API REST pour les visiteurs » ou similaire) ; vérifiez qu’il accepte une liste d’exceptions et répond 404, et non 401.

Déconseillé : l’extrait de code courant qui refuse toute l’API aux visiteurs via rest_authentication_errors. Il casse les formulaires et le panier en blocs, et répond encore 401 pour chaque adresse, ce qui confirme que chaque extension existe.

3. Vérifier. Ouvrez https://example.com/wp-json/ dans une fenêtre privée : la réponse doit être « introuvable » (404, rest_no_route). Envoyez ensuite un formulaire et utilisez le panier ou tout ce que font vos pages, puis relancez cette vérification. 

Hide my WordPress site's REST API map from visitors who are not logged in, without breaking the features that use the API. https://example.com/wp-json/ currently answers anyone and lists every namespace, i.e. every plugin.

Do this:
1. Find which namespaces the public pages call (forms, cart, checkout, view counters): grep the theme and plugins for wp-json / rest_url / apiFetch, and check the browser's network tab as a visitor.
2. Add a must-use plugin (wp-content/mu-plugins/hide-rest-map.php) with a rest_endpoints filter: when the user cannot edit_posts, unset every route except those under the kept namespaces (match '/<namespace>/' as a prefix of the route), so the index '/', every namespace index and the other routes answer 404 rest_no_route, never 401. Also remove_action wp_head rest_output_link_wp_head and template_redirect rest_output_link_header (priority 11).
3. Do not use rest_authentication_errors to refuse the whole API: it breaks visitor-facing features and answers 401, which confirms the plugins.
4. Verify: /wp-json/ and /wp-json/wp/v2 answer 404 for a visitor and still work for an editor; the kept features work in a private window; no <link rel="https://api.w.org/"> and no Link header on the pages.
Tell me exactly which file you added and which namespaces you kept.

Analysez votre site pour savoir s’il a ce problème. Analyser un site