« Comment déclencher une réindexation depuis une interface d’administration personnalisée, sans que la clé capable d’écrire dans l’index ne transite jamais vers le navigateur ? » Cette question s’est posée sur un projet où une extension interne, développée pour une équipe éditoriale, devait permettre de relancer manuellement l’indexation Algolia d’une catégorie de produits depuis un bouton dans l’administration WordPress, sans dépendre du cycle de synchronisation automatique habituel.
La tentation initiale, courante sur ce type de besoin, consiste à appeler directement l’API Algolia depuis un script JavaScript de l’administration, avec la clé d’écriture intégrée dans le code. Cette approche fonctionne techniquement, mais expose une clé capable de modifier l’intégralité de l’index à quiconque inspecte le code source de la page d’administration, y compris un compte compromis n’ayant normalement aucun droit d’administration Algolia.
Le problème : une clé d’écriture n’a rien à faire côté client
Contrairement à une clé de recherche, pensée dès sa conception pour être publique, une clé d’écriture Algolia (souvent la clé API principale ou une clé d’administration) permet de créer, modifier et supprimer des objets dans l’index. Sa présence dans n’importe quel code exécuté côté navigateur, même dans une interface d’administration a priori réservée aux utilisateurs de confiance, constitue une exposition disproportionnée par rapport au besoin réel : déclencher une action précise et prédéfinie, pas donner un accès libre à l’API Algolia.
La solution : une route REST comme proxy contrôlé
Le principe du proxy consiste à créer une route REST WordPress qui reçoit la demande de réindexation depuis le navigateur (sans aucune clé Algolia dans cette requête), vérifie les droits de l’utilisateur connecté, puis effectue elle-même l’appel vers Algolia depuis le serveur, où la clé d’écriture reste stockée en variable d’environnement, jamais transmise au client.
add_action('rest_api_init', function () {
register_rest_route('admin-tools/v1', '/reindex-categorie', [
'methods' => 'POST',
'callback' => 'reindexer_categorie_algolia',
'permission_callback' => function () {
return current_user_can('manage_woocommerce');
},
'args' => [
'categorie_id' => ['required' => true, 'validate_callback' => 'is_numeric'],
],
]);
});
function reindexer_categorie_algolia(WP_REST_Request $request) {
$categorie_id = (int) $request->get_param('categorie_id');
$produits = get_posts([
'post_type' => 'product',
'category' => $categorie_id,
'posts_per_page' => -1,
]);
$client = \Algolia\AlgoliaSearch\SearchClient::create(
'APPID',
getenv('ALGOLIA_ADMIN_KEY')
);
$index = $client->initIndex('produits_index');
$objets = array_map('formater_produit_pour_algolia', $produits);
$index->saveObjects($objets, ['autoGenerateObjectIDIfNotExist' => true]);
return ['statut' => 'ok', 'nombre_produits' => count($objets)];
}
Ce que ce cloisonnement change concrètement
Après la mise en place de ce proxy, le nombre de requêtes directes émises vers l’API Algolia depuis le navigateur de l’administration est retombé à zéro, seul le point de terminaison WordPress recevant désormais des requêtes du client. La clé d’écriture Algolia n’apparaît plus jamais dans les outils de développement du navigateur, ni dans aucun code servi au client, ce qui réduit sa surface d’exposition au seul environnement serveur, protégé par les mécanismes classiques de sécurisation de wp-config.php et des variables d’environnement.
Ne pas négliger la validation même sur une route interne
Le fait que cette route ne soit accessible qu’à des utilisateurs disposant de la capacité manage_woocommerce ne dispense pas de valider strictement le paramètre categorie_id reçu : un compte compromis ou un script malveillant exécuté dans le contexte d’une session administrateur légitime (par exemple via une faille XSS ailleurs sur le site) pourrait sinon appeler cette route avec des paramètres inattendus. La validation par validate_callback et le contrôle de capacité se complètent, ils ne se substituent pas l’un à l’autre.
Variantes possibles
Ce même schéma de proxy s’applique à d’autres besoins d’indexation : déclenchement via une commande WP-CLI personnalisée pour les réindexations planifiées côté serveur, ou file d’attente asynchrone via wp_schedule_single_event pour les catalogues volumineux où une réindexation synchrone risquerait de dépasser le délai d’exécution PHP autorisé.
En résumé
Une clé capable d’écrire dans un index de recherche ne devrait jamais avoir de raison de transiter vers un navigateur, quel que soit le niveau de confiance accordé à l’utilisateur qui déclenche l’action. Une route REST dédiée, avec un contrôle de capacité et une validation stricte des paramètres, permet d’obtenir la même fonctionnalité côté interface sans jamais exposer ce qui doit rester strictement côté serveur.
