# Sécuriser le back-office d’un WordPress headless : la checklist > WordPress ne sert plus qu'à alimenter un front découplé ? Voici tout ce qu'il faut verrouiller côté back-office avant la mise en ligne. - Auteur : Clément Hadrot - Publié le : 2023-09-29 - Mis à jour le : 2023-09-29 - Catégorie : Headless & API - URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/securiser-back-office-wordpress-headless-checklist/ ## L’essentiel - Masquer le front WordPress inutile derrière une redirection - Fermer les routes REST et GraphQL qui n'ont plus de raison d'être publiques - Restreindre l'accès à l'administration elle-même 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_redirect` facilement contournable. - Vérifier qu'aucun thème actif ne fuit d'informations dans son `` (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-admin` et `/wp-login.php` par 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_EDIT` définie à `true`. - Désactiver `xmlrpc.php` s'il n'est utilisé par aucun outil du projet, cible classique de force brute. > L'essentiel à retenir : Masquer le front WordPress inutile derrière une redirection ; Fermer les routes REST et GraphQL qui n'ont plus de raison d'être publiques ; Restreindre l'accès à l'administration elle-même ## 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.