L’autoload de wp_options peut révéler une donnée sensible mal sérialisée

La table wp_options comporte une colonne autoload, réglée à yes ou no pour chaque ligne. Une valeur yes indique à WordPress de charger cette option en mémoire dès l’initialisation du cœur, via la fonction wp_load_alloptions(), sans attendre qu’un appel explicite à get_option() ne la réclame. Cette mécanique, pensée pour la performance, a une conséquence directe sur l’exposition des données qu’elle transporte.

Ce que l’autoload signifie concrètement

Une option marquée autoload=yes se retrouve chargée en mémoire à chaque exécution de WordPress, qu’elle soit utilisée ou non par la page en cours de traitement. Cette mémoire peut être mise en cache dans un cache d’objet persistant, exposée dans un rapport de débogage détaillé, ou visible dans un dump mémoire produit par un outil de diagnostic serveur. Une donnée sensible stockée dans une telle option n’est donc jamais confinée au seul moment où le code applicatif la lit explicitement.

Fonctionnement interne : sérialisation, pas chiffrement

Quand une option contient un tableau ou un objet PHP, WordPress la sérialise automatiquement avant de l’enregistrer en base de données, via maybe_serialize(). Cette sérialisation transforme la structure de données en une chaîne de caractères, mais ne la chiffre en aucune façon : une valeur sensible imbriquée dans un tableau sérialisé reste parfaitement lisible en clair pour quiconque consulte la ligne correspondante, que ce soit dans la table elle-même ou dans un cache d’objet qui en conserve une copie en mémoire.

Cas d’usage où ce risque se manifeste

• Une extension qui stocke une clé d’API tierce dans une option de configuration marquée autoload=yes par défaut, sans distinction entre les réglages sensibles et les réglages d’affichage.
• Un identifiant de compte de service, enregistré via update_option() sans préciser explicitement le paramètre d’autoload, ce qui conserve la valeur par défaut historique de WordPress.
• Un outil de diagnostic ou de support technique qui affiche l’ensemble des options autoloadées pour analyser un problème de performance, exposant au passage leur contenu à quiconque a accès à cet outil.

Ce qu’il faut vérifier et corriger

La fonction update_option() accepte un troisième paramètre optionnel permettant de préciser explicitement si l’option doit être autoloadée, avec la valeur booléenne false pour l’en exclure :

update_option('cle_api_service_facturation', $cle_chiffree, false);

Pour un audit d’options existantes, une requête directe sur la base permet d’identifier les lignes marquées autoload=yes dont le nom laisse supposer un contenu sensible, comme une clé, un jeton ou un identifiant de connexion, en vue de corriger leur paramètre d’autoload et, plus fondamentalement, de vérifier si leur valeur devrait être chiffrée avant stockage plutôt que simplement exclue de l’autoload.

Exclure une donnée sensible de l’autoload réduit sa surface d’exposition en mémoire, mais ne remplace jamais un chiffrement au repos si la donnée le justifie.

Les pièges à éviter

Retirer l’autoload d’une option très fréquemment consultée peut dégrader la performance du site, chaque appel à get_option() déclenchant alors une requête individuelle vers la base de données au lieu de puiser dans le tableau déjà chargé en mémoire. L’arbitrage entre performance et exposition doit se faire option par option, en fonction de la fréquence d’utilisation réelle et de la sensibilité du contenu stocké, jamais de façon uniforme sur l’ensemble de la table.

Repérer les options existantes concernées

Une commande WP-CLI comme wp option list --autoload=on --format=csv extrait la liste complète des options actuellement autoloadées sur une installation, ce qui permet une revue manuelle ciblée sur les noms évocateurs d’un contenu sensible, sans avoir à parcourir l’ensemble de la table wp_options ligne par ligne dans un client SQL. Cette revue devrait figurer dans la checklist d’un audit de sécurité, au même titre que la vérification des comptes utilisateurs ou des capacités attribuées.

En résumé

L’autoload de wp_options répond à un besoin réel de performance, mais charge en mémoire, à chaque requête, l’ensemble des options ainsi marquées, sans distinction de sensibilité. Une donnée sensible stockée dans une option autoloadée et non chiffrée reste exposée à toute méthode d’accès à cette mémoire, bien au-delà du seul appel explicite à get_option() par le code applicatif.