Vos clés d'API IA dans WordPress : où elles sont, comment elles sont chiffrées

Pour faire fonctionner son copilote, StormPress vous demande une clé d'API chez Anthropic ou OpenAI. Cette clé donne le droit de consommer — et donc de facturer — des appels en votre nom. Si elle fuit, quelqu'un d'autre s'en sert à vos frais.

Or la base de données d'un site WordPress circule plus qu'on ne le croit : sauvegardes envoyées sur un stockage externe, copies vers un environnement de préproduction, export transmis à un prestataire, dump joint à un ticket de support. Une clé stockée en clair voyage avec chacune de ces copies.

Ce qui est stocké, et sous quelle forme

StormPress ne range jamais une clé d'API en clair. Chaque clé d'API est chiffrée avant d'être écrite dans la table des options :

• Algorithme : AES-256-GCM, un chiffrement authentifié. Il garantit la confidentialité de la valeur, mais aussi son intégrité : une valeur altérée est rejetée au lieu d'être déchiffrée de travers.
• Clé maîtresse : dérivée des constantes secrètes AUTH_KEY et SECURE_AUTH_KEY, sur une installation standard, où ces constantes sont définies dans wp-config.php. Elle n'est jamais écrite en base.
• Clé par valeur : pour chaque secret, une clé distincte est dérivée par PBKDF2-SHA256 (10 000 itérations) avec un sel aléatoire de 16 octets, puis la valeur est chiffrée avec un vecteur d'initialisation aléatoire de 12 octets.

Dans la base, une clé ressemble donc à ceci, et rien d'autre :

enc:<sel>:<iv>:<étiquette>:<texte chiffré>

Conséquence pratique : un dump de la base, seul, ne suffit pas, sur une installation standard, à retrouver vos clés. Il faut aussi le fichier wp-config.php, qui ne voyage normalement pas avec les sauvegardes de base.

Le même mécanisme protège le secret qui signe les jetons de session de StormPress : il est chiffré dès le premier chargement du site qui suit l'activation. Et si vous mettez à jour depuis une ancienne version qui stockait une clé en clair, elle est chiffrée automatiquement à sa première lecture.

Ce qui part chez le fournisseur d'IA

Le copilote n'envoie rien tant que vous ne lui écrivez pas. Quand vous lui envoyez un message, votre serveur contacte directement le fournisseur que vous avez choisi — api.anthropic.com ou api.openai.com — et lui transmet :

• votre demande ;
• l'historique de la conversation en cours ;
• le nom et la langue du site, qui figurent dans ses instructions ;
• les données que le copilote lit pour vous répondre, par exemple le texte d'un article et ses métadonnées SEO, les statistiques du site, la liste de vos extensions ou l'état technique du site (base de données, espace disque, intégrité des fichiers).

Deux commandes de la palette s'adressent aussi au fournisseur, hors du copilote. /extrait lui envoie le nom et la langue du site, le titre de l'article et ses 1 200 premiers caractères ; sans clé saisie dans StormPress, il passe par le client IA de WordPress, vers le fournisseur que vous y avez configuré, et le nom du site ne part pas. /lier, quand une clé est saisie dans StormPress, lui envoie le titre, les 1 500 premiers caractères et les titres d'au plus trente contenus candidats du site ; sans clé, ses suggestions se font par popularité, sans aucun appel.

Rien ne transite par les serveurs de Stormeo. L'historique de conversation n'est pas conservé sur votre serveur : il vit dans votre onglet et disparaît quand vous l'effacez. Ce qui est envoyé au fournisseur relève ensuite de ses propres conditions ; elles sont citées dans la documentation du plugin, et c'est à vous de choisir celui dont la politique vous convient.

Ce que ce chiffrement ne protège pas

Un chiffrement ne vaut que par son modèle de menace. Voici le nôtre, sans enjolivement.

• Un accès complet au serveur. Quelqu'un qui lit à la fois la base de données et wp-config.php peut reconstituer la clé maîtresse. C'est inévitable : votre site doit pouvoir déchiffrer la clé pour appeler le fournisseur, donc tout ce qu'il faut pour la déchiffrer se trouve sur le serveur. Le chiffrement protège les copies de la base, pas un serveur compromis.
• Les comptes du site. Un administrateur peut remplacer la clé ; tout compte disposant de la capacité edit_posts peut utiliser le copilote à vos frais, dans la limite de débit fixée par utilisateur. Les droits WordPress restent la première barrière.
• Un code malveillant installé sur le site. Une extension compromise s'exécute avec les mêmes droits que StormPress. Aucune extension ne peut s'en protéger seule.

Si vous changez vos clés secrètes WordPress

Régénérer les constantes AUTH_KEY et SECURE_AUTH_KEY est une bonne pratique après un incident : cela déconnecte toutes les sessions. Sachez simplement que la clé maîtresse en dérive. Après ce changement, les clés d'API chiffrées ne sont plus lisibles : le copilote se comporte comme si aucune clé n'était configurée, même si la page des réglages IA indique encore « Clé configurée ». Saisissez-les à nouveau dans ces réglages. Si le site est relié à StormeoOS, refaites aussi la liaison : ses identifiants sont chiffrés de la même façon.

C'est le comportement attendu, pas une panne. Une clé qu'on pourrait encore déchiffrer après la rotation des secrets serait une clé mal protégée.

En résumé

• Vos clés sont chiffrées en AES-256-GCM, avec une clé dérivée de wp-config.php qui n'est jamais stockée en base.
• Les requêtes partent de votre serveur vers le fournisseur choisi (pour /extrait sans clé StormPress, celui configuré dans WordPress), et seulement quand vous utilisez le copilote, /extrait ou /lier.
• Sur une installation standard, une sauvegarde de base seule ne révèle pas vos clés ; un serveur entièrement compromis, si.
• Après une rotation des secrets WordPress, ressaisissez vos clés.

Le chiffrement des clés au repos fait partie des correctifs de sécurité livrés cet été. Nous racontons les autres, et pourquoi nous les publions, dans notre retour sur les correctifs de juillet.

• sécurité
• chiffrement
• AES-256-GCM
• clés API
• vie privée