{ __schema { types { name fields { name } } } }. Cette unique requête d’introspection, envoyée à n’importe quel endpoint GraphQL qui ne la désactive pas explicitement, retourne l’intégralité des types et des champs disponibles dans le schéma. Sur un projet WPGraphQL couplé à Advanced Custom Fields, cette liste inclut par défaut tous les groupes de champs déclarés dans l’administration, y compris ceux qui n’ont jamais été pensés pour quitter le back-office.
Un développeur découvre ce comportement en explorant le schéma d’un projet repris récemment : parmi les champs exposés sur le type Produit, une note interne destinée à l’équipe commerciale — marge appliquée, remarque sur un fournisseur — apparaît telle quelle, accessible à quiconque interroge le point d’entrée GraphQL public.
Pourquoi l’exposition automatique existe
L’extension WPGraphQL for Advanced Custom Fields, qui relie les groupes de champs ACF au schéma GraphQL généré par WPGraphQL, applique par défaut une règle simple : tout groupe de champs coché comme visible dans l’API REST ou associé à un type de contenu exposé au schéma devient automatiquement disponible en lecture via GraphQL. Cette automatisation, pensée pour accélérer le développement, ne distingue pas nativement une donnée destinée à un usage interne d’une donnée destinée à l’affichage public.
Le piège du champ ajouté rapidement
Le scénario typique se produit lors de l’ajout d’un champ ACF en cours de projet, pour un besoin ponctuel côté administration : une remarque, un statut interne, une référence fournisseur. Le développeur qui l’ajoute pense rarement à vérifier son impact sur le schéma déjà exposé, d’autant que rien dans l’interface ACF ne signale explicitement cette conséquence au moment de la création du champ.
Diagnostiquer l’étendue du problème
Une requête d’introspection ciblée sur un type précis permet de vérifier rapidement ce qui est exposé :
query VerifierChampsProduit {
__type(name: "Produit") {
fields {
name
description
}
}
}
Comparer cette liste avec la liste des champs réellement consommés par le front révèle souvent un écart significatif : des champs présents dans le schéma, jamais requêtés par aucune application connue, dont l’existence même n’était plus dans la mémoire de l’équipe.
Corriger : restreindre champ par champ
La restriction s’effectue au niveau du filtre de résolution de champ, plutôt qu’en tentant de retirer un groupe entier, ce qui casserait potentiellement d’autres usages légitimes du même groupe :
add_action( 'graphql_register_types', function () {
register_graphql_field( 'Produit', 'remarqueInterne', array(
'type' => 'String',
'resolve' => function () {
return null; // Jamais résolu côté public
},
) );
} );Une approche plus radicale consiste à retirer entièrement le champ du schéma via le filtre graphql_Product_fields ou son équivalent selon la version, plutôt que de le neutraliser côté résolveur, ce qui a l’avantage de ne plus l’exposer non plus à l’introspection elle-même.
Une protection complémentaire : désactiver l’introspection en production
Au-delà du traitement champ par champ, une protection plus générale consiste à désactiver la requête d’introspection sur l’environnement de production, ou à la réserver aux requêtes authentifiées avec un rôle de développement. WPGraphQL propose un réglage dans ses paramètres généraux pour restreindre l’introspection aux seuls utilisateurs connectés disposant de la capacité appropriée.
- Vérifier régulièrement, à chaque ajout de champ ACF, son impact potentiel sur le schéma GraphQL exposé.
- Retirer explicitement du schéma tout champ à usage strictement interne, plutôt que de compter sur l’absence de requête côté front.
- Envisager la restriction de l’introspection en production pour réduire la surface de découverte du schéma complet.
Un schéma généré automatiquement reflète fidèlement ce qui a été déclaré côté administration, pas ce qui était destiné à un usage public. Cette nuance doit rester présente à l’esprit à chaque ajout de champ, pas seulement lors de l’audit initial du projet.
En résumé
L’automatisation qui relie les champs personnalisés au schéma GraphQL constitue un gain de temps réel, mais déplace la responsabilité de la confidentialité vers chaque ajout de champ individuel plutôt que vers un point de contrôle central. Une revue régulière du schéma exposé, via une simple requête d’introspection ciblée, reste le moyen le plus direct de repérer ce type d’oubli avant qu’il ne soit découvert par quelqu’un d’autre.
