Quand WordPress devient une simple source de contenu pour un front Next.js ou Nuxt, son propre thème et sa propre page d’accueil ne servent plus jamais un visiteur réel. Beaucoup d’équipes oublient pourtant de fermer ce qui n’a plus lieu d’exister : le thème public reste accessible, les routes GraphQL exposent tout le schéma en introspection, et l’admin traîne sur son URL par défaut. Voici la liste de contrôle utilisée avant chaque mise en production d’un projet headless.
Elle ne revient pas sur les mécanismes d’authentification de l’API eux-mêmes, déjà traités ailleurs : elle se concentre sur tout ce qui entoure le back-office et qui reste trop souvent grand ouvert par défaut.
Fermer le front public inutilisé
- Rediriger toutes les requêtes frontales vers le vrai domaine du front découplé, via une règle au niveau du serveur web plutôt qu’un simple
wp_redirectfacilement contournable. - Vérifier qu’aucun thème actif ne fuit d’informations dans son
<head>(version de WordPress, chemins de plugins) même si personne n’est censé le visiter. - Désactiver les flux RSS s’ils ne sont pas utilisés, via le filtre
do_feed.
Restreindre l’accès à l’administration
- Limiter l’accès à
/wp-adminet/wp-login.phppar une liste d’adresses IP autorisées côté serveur web, en plus de l’authentification WordPress. - Désactiver l’éditeur de fichiers de thèmes et d’extensions avec la constante
DISALLOW_FILE_EDITdéfinie àtrue. - Désactiver
xmlrpc.phps’il n’est utilisé par aucun outil du projet, cible classique de force brute.
Fermer les routes REST superflues
Un WordPress headless expose souvent bien plus que ce dont le front a réellement besoin. Le filtre rest_endpoints permet de retirer chirurgicalement les routes non utilisées (utilisateurs, réglages, blocs réutilisables) sans toucher à celles qui alimentent réellement le front.
add_filter( 'rest_endpoints', function( $endpoints ) {
unset( $endpoints['/wp/v2/users'] );
return $endpoints;
} );
La route /wp/v2/users mérite une attention particulière : par défaut, elle peut révéler les identifiants et noms d’affichage des comptes ayant publié du contenu, une information précieuse pour préparer une attaque ciblée.
Restreindre l’introspection GraphQL
Sur un projet WPGraphQL, l’introspection publique permet à n’importe qui de reconstituer le schéma complet de l’API, y compris des champs sensibles jamais consommés par le front officiel. Les réglages de WPGraphQL permettent de désactiver l’introspection en production, tout en la gardant active en environnement de développement pour les outils comme les générateurs de types.
Réduire la surface d’attaque restante
| Élément | Action recommandée |
|---|---|
| Comptes administrateurs | Authentification à deux facteurs obligatoire |
| Extensions installées | Limiter au strict nécessaire, désactiver les inutilisées |
| Journalisation | Conserver les tentatives de connexion échouées |
Surveiller après la mise en ligne, pas seulement avant
Une checklist appliquée une seule fois au lancement perd de sa valeur avec le temps : une extension mise à jour peut rouvrir une route désactivée, un réglage peut être réinitialisé après une restauration de sauvegarde mal ciblée. Sur les projets qu’on maintient dans la durée, un contrôle automatisé rejoue périodiquement les principales vérifications (routes REST fermées, introspection GraphQL désactivée, éditeur de fichiers verrouillé) et alerte dès qu’un écart apparaît par rapport à l’état attendu.
Un dernier point souvent oublié
Les identifiants de contenu (articles, pages, médias) restent parfois devinables par simple incrémentation via l’API REST. Ce n’est pas une faille en soi, mais combiné à des routes trop bavardes, cela facilite l’énumération de contenus non censés être publics, comme des brouillons mal protégés.
Une checklist de sécurité qui n’est jamais rejouée après la mise en ligne perd tout son intérêt : chaque nouvelle extension ou chaque nouveau champ personnalisé doit repasser par les mêmes questions.
Pour aller plus loin
Cette liste n’est pas exhaustive et doit être adaptée à chaque projet : un site multi-auteurs n’a pas les mêmes besoins qu’un site à un seul rédacteur, un projet e-commerce headless doit ajouter ses propres contrôles autour des données de paiement. Le principe qui reste constant : tout ce que le front ne consomme pas explicitement devrait être fermé par défaut, pas laissé ouvert par habitude.
