# Proxifier les appels d’indexation Algolia sans exposer la clé d’écriture

> Plutôt que d'exposer une clé capable d'écrire dans l'index Algolia depuis un contexte non fiable, ce snippet montre comment proxifier les appels d'indexation depuis WordPress.

- Auteur : WordPress Développement
- Publié le : 2022-06-10
- Mis à jour le : 2022-06-10
- Catégorie : Sécurité
- URL : https://www.wpmoderne.fr/securite/proxifier-indexation-algolia-cle-ecriture/

## L’essentiel

- Une clé d'indexation ne doit jamais quitter le serveur
- Une route REST dédiée limite précisément ce qui peut être déclenché
- La validation des paramètres reste indispensable même sur une route interne

« 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)];
}
```

> L'essentiel à retenir : Une clé d'indexation ne doit jamais quitter le serveur ; Une route REST dédiée limite précisément ce qui peut être déclenché ; La validation des paramètres reste indispensable même sur une route interne

## 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.