Une API REST expose systématiquement plus de données que ce qu’un front consomme réellement : c’est un fait structurel, pas une négligence isolée. Sur le site vitrine d’un centre hospitalier proposant la prise de rendez-vous en ligne via un WordPress headless, ce constat a pris une tournure sérieuse : plusieurs champs personnalisés liés aux fiches de rendez-vous, jamais affichés par le front, restaient accessibles en clair via l’endpoint wp/v2/rendez_vous pour quiconque connaissait l’URL.
Cette checklist recense les champs à exclure ou à pseudonymiser côté WordPress avant qu’une API REST publique ne les expose, sans entrer dans la question de l’hébergement des données de santé elles-mêmes, qui relève d’un cadre réglementaire distinct (HDS) et d’un choix d’infrastructure à part.
Pourquoi l’exposition par défaut surprend souvent
Un champ ACF ajouté à un type de contenu personnalisé, dès lors que ce type est enregistré avec show_in_rest => true, apparaît automatiquement dans la réponse de l’API REST via le sous-objet acf, sans qu’aucune action explicite ne soit nécessaire pour l’exposer. Beaucoup d’équipes découvrent ce comportement après coup, en constatant qu’un champ jamais affiché par le front est pourtant lisible en clair dans la réponse JSON brute.
La checklist avant mise en production
- Lister l’intégralité des champs personnalisés (ACF ou meta natives) attachés au type de contenu exposé en REST, sans se fier uniquement à ce que le front affiche.
- Identifier parmi eux les champs contenant une donnée directement identifiante (nom, numéro de sécurité sociale, date de naissance complète) ou une donnée médicale (motif de consultation, traitement en cours).
- Pour chaque champ sensible identifié, décider explicitement : exclusion totale de l’API, ou pseudonymisation avant exposition.
- Vérifier que les rôles disposant d’un accès authentifié à l’API (personnel administratif) ne voient exposés que les champs strictement nécessaires à leur usage, via un contrôle de capacité.
- Retester après chaque ajout de champ ACF : cette checklist n’est pas un contrôle ponctuel, mais une vérification à répéter à chaque évolution du type de contenu.
Exclure un champ de l’API REST
Le filtre rest_prepare_{$post_type} permet de retirer explicitement un champ de la réponse juste avant son envoi, quelle que soit la manière dont il a été ajouté initialement :
add_filter('rest_prepare_rendez_vous', function ($response, $post, $request) {
$data = $response->get_data();
unset($data['acf']['motif_consultation']);
unset($data['acf']['numero_secu']);
unset($data['acf']['notes_internes']);
$response->set_data($data);
return $response;
}, 10, 3);Cette approche reste explicite et facile à auditer : chaque exclusion est visible en un coup d’œil dans une seule fonction, plutôt que dispersée dans la configuration de chaque champ ACF individuellement.
Pseudonymiser plutôt qu’exclure
Certains champs restent utiles au front sous une forme partielle : afficher les initiales d’un patient dans un espace personnel authentifié, sans exposer son nom complet dans la réponse brute de l’API, par exemple. Le même filtre permet cette transformation :
add_filter('rest_prepare_rendez_vous', function ($response, $post, $request) {
$data = $response->get_data();
if (!empty($data['acf']['nom_patient'])) {
$mots = explode(' ', $data['acf']['nom_patient']);
$data['acf']['nom_patient'] = implode(' ', array_map(
fn($mot) => mb_substr($mot, 0, 1) . '.',
$mots
));
}
$response->set_data($data);
return $response;
}, 10, 3);Ce que la checklist ne couvre pas
Cette checklist porte exclusivement sur la surface d’exposition de l’API REST, une fois le contenu déjà stocké dans WordPress. Elle ne traite ni du chiffrement au repos, ni de l’hébergement conforme aux exigences applicables aux données de santé, deux sujets qui relèvent du choix d’infrastructure et du prestataire d’hébergement, indépendamment de la configuration applicative décrite ici.
- Un champ exclu de l’API REST publique doit l’être aussi de tout endpoint personnalisé ajouté ultérieurement au même type de contenu.
- Un accès authentifié (personnel soignant) n’est pas une excuse pour exposer davantage de champs que nécessaire à cet usage précis.
- La revue de cette checklist doit être intégrée au processus de recette, pas laissée à la mémoire de l’équipe.
Le champ le plus dangereux d’une API n’est presque jamais celui qu’on affiche par erreur : c’est celui qu’on a oublié d’exclure, parce que le front, lui, ne l’a jamais demandé.
En résumé
Un WordPress headless expose, par défaut, tout ce qu’il sait sur un contenu, indépendamment de ce que le front en affiche réellement. Sur un projet manipulant des données sensibles, cette checklist doit devenir un réflexe systématique à chaque ajout de champ, et non une vérification a posteriori une fois le problème découvert en production.
