Une seule ligne, dans un fichier search.js chargé par le thème enfant : algoliasearch('APPID', 'f3a1c9...'). Rien d’inhabituel en apparence, sauf que la seconde chaîne n’était pas une clé de recherche publique mais la clé d’administration complète du compte Algolia.
Ce genre d’erreur ne saute pas aux yeux dans une revue de code rapide : les deux types de clés ont exactement la même forme, une chaîne alphanumérique de 32 caractères, et rien dans leur apparence n’indique leurs permissions respectives.
Symptôme : un index qui se vide sans explication
L’alerte est venue d’un client signalant que la recherche du site ne retournait plus aucun résultat depuis la veille. Le tableau de bord Algolia confirmait : l’index principal, qui contenait plusieurs milliers d’entrées de catalogue, était passé à zéro document du jour au lendemain, sans qu’aucune tâche d’indexation planifiée n’ait été modifiée côté WordPress.
Les journaux d’API Algolia montraient un appel clearObjects exécuté depuis une adresse IP inconnue, avec la clé d’administration du compte. Aucune trace de compromission du serveur WordPress lui-même : le point d’entrée n’était pas le serveur, mais le navigateur de n’importe quel visiteur du site.
Diagnostic : une clé admin exposée côté client
Algolia distingue clairement deux familles de clés. La clé d’administration (Admin API Key) peut créer, modifier et supprimer des index, gérer les paramètres de recherche et même créer d’autres clés API. Les clés de recherche, elles, sont conçues pour être publiques : elles n’autorisent que des requêtes de lecture, et peuvent être restreintes par index, par IP ou par durée de validité.
Sur ce projet, un développeur avait copié un exemple de documentation utilisant la clé admin pour tester rapidement l’intégration en local, puis avait oublié de la remplacer par une clé de recherche avant de livrer le thème enfant en production. Le fichier JavaScript, servi tel quel par le navigateur, exposait donc cette clé à quiconque ouvrait les outils de développement.
Correctif : générer des clés à portée strictement limitée
La correction s’est faite en trois temps. D’abord, révocation immédiate de la clé compromise depuis le tableau de bord Algolia, ce qui invalide instantanément tous les appels qui l’utilisent. Ensuite, génération d’une clé de recherche restreinte à l’index concerné, avec l’API generateSecuredApiKey côté serveur PHP pour pouvoir, plus tard, limiter aussi les filtres appliqués par utilisateur si besoin :
$client = \Algolia\AlgoliaSearch\SearchClient::create(
'APPID',
getenv('ALGOLIA_ADMIN_KEY')
);
$publicKey = $client->generateSecuredApiKey(
getenv('ALGOLIA_SEARCH_KEY'),
['restrictIndices' => 'produits_index', 'validUntil' => time() + 3600]
);Enfin, réindexation complète du catalogue via WP-CLI et une commande personnalisée qui parcourt les articles publiés, seule solution pour reconstituer un index vidé par erreur.
Prévention : ne jamais faire confiance à l’apparence d’une clé
Depuis cet incident, la revue de code du projet inclut systématiquement une recherche du motif ALGOLIA_ADMIN ou de toute variable contenant le mot admin dans l’ensemble des fichiers destinés à être servis au navigateur, y compris les fichiers compilés par un bundler. Un script de build refuse désormais la mise en production si ce motif est détecté dans le dossier dist.
Autre réflexe adopté : générer systématiquement les clés de recherche avec une portée explicite (index, filtres, durée) plutôt que d’utiliser la clé de recherche générique du compte, qui reste elle aussi plus permissive qu’elle n’a besoin de l’être pour un usage précis.
Notre verdict
Le coût de cet incident a été limité : quelques heures de réindexation et une révocation de clé, sans perte de données côté WordPress. Mais la cause profonde méritait d’être traitée sérieusement, car la même erreur, sur un index contenant des données personnelles plutôt qu’un catalogue produit, aurait eu des conséquences bien plus lourdes. Le principe reste identique quel que soit le service tiers utilisé : une clé qui transite vers le navigateur doit être générée pour cet usage précis, jamais recopiée depuis un exemple de documentation destiné à un contexte serveur.
