Dans le fichier app/etc/env.php de chaque installation Magento 2 se trouve une chaîne de caractères discrète, sous la clé crypt.key. Elle ne ressemble à rien de spécial — une suite hexadécimale de 64 caractères — mais c’est l’un des secrets les plus sensibles de toute votre boutique. Si elle est perdue, une partie de vos données devient définitivement illisible. Si elle est volée, un attaquant peut potentiellement déchiffrer des informations sensibles ou forger un accès complet à votre administration.
Voici ce que cette clé fait réellement, comment Magento l’utilise, et comment la gérer sans mettre votre boutique en péril.
Ce que la clé de chiffrement protège concrètement
Cette clé sert à chiffrer et déchiffrer les données sensibles que Magento a besoin de relire en clair par la suite — contrairement aux mots de passe, qui eux sont hachés à sens unique et jamais déchiffrés. La documentation officielle Adobe est claire sur ce point : un algorithme ChaCha20-Poly1305 avec une clé de 256 bits est utilisé pour chiffrer toutes les données nécessitant un déchiffrement, tandis qu’un algorithme SHA-256 sert à hacher les données qui n’en ont pas besoin (source : Adobe Experience League, documentation « Encryption key »).
Ce que la clé de chiffrement protège
Données de cartes bancaires enregistrées (tokens de paiement)
Mots de passe des modules d’intégration paiement et livraison
Certains champs de configuration marqués comme chiffrés
Les mots de passe clients et admin ne passent jamais par la crypt-key : ils sont hachés à sens unique. Magento vérifie un mot de passe en le re-hachant à la connexion, il ne le déchiffre jamais.
Cette distinction est importante et souvent confondue : la crypt-key n’a strictement rien à voir avec le stockage des mots de passe. Elle sert uniquement au chiffrement réversible — ce que l’application doit pouvoir relire plus tard pour renvoyer un token à un prestataire de paiement, ou réutiliser une clé API tierce.
Où elle vit, et pourquoi ce fichier ne doit jamais être versionné
La clé est générée aléatoirement à l’installation et stockée dans app/etc/env.php, sous la structure 'crypt' => ['key' => '...']. Ce même fichier contient aussi les identifiants de connexion à votre base de données, le nom de domaine de votre back-office et la configuration des cookies de session. Autrement dit : c’est probablement le fichier le plus sensible de toute votre installation Magento.
La règle absolue : ce fichier ne doit jamais être commité dans un dépôt Git. Il est exclu par défaut via .gitignore sur une installation Magento standard — mais des réécritures de .gitignore personnalisées finissent parfois par l’oublier, et un simple git add app/etc suffit à exposer l’intégralité de vos secrets dans l’historique du dépôt, de façon quasiment irréversible même après une suppression ultérieure.
Pourquoi cette clé est une cible de choix pour un attaquant
Ce n’est pas un risque théorique. La vulnérabilité CosmicSting (CVE-2024-34102, CVSS 9.8), l’une des failles Magento les plus exploitées de ces dernières années, illustrait précisément ce danger : une faille d’injection XML permettait à un attaquant non authentifié de lire des fichiers arbitraires sur le serveur — dont app/etc/env.php. Une fois la clé de chiffrement en main, l’attaquant pouvait forger des jetons d’authentification valides et obtenir un accès administrateur complet, sans jamais connaître le moindre mot de passe. Cette vulnérabilité a conduit à plus de 4 275 boutiques compromises.
C’est la raison pour laquelle, sur une boutique qui a pu être exposée à une faille de ce type, changer les mots de passe ne suffit jamais : il faut aussi faire tourner (rotation) la clé de chiffrement elle-même, sans quoi l’ancienne clé reste valide pour forger de nouveaux accès.
Changer la clé : ce qui a changé en 2.4.8
Point d’actualité important si vous gérez plusieurs boutiques Magento : la fonctionnalité de changement de clé de chiffrement depuis l’interface d’administration est désormais dépréciée et a été retirée en Magento 2.4.8. La documentation officielle Adobe est explicite sur ce point : depuis cette version, il faut obligatoirement utiliser la commande en ligne de commande pour changer la clé après une mise à niveau vers 2.4.8 (source : Adobe Experience League, documentation « Encryption key »).
Les grandes étapes d’un changement de clé sécurisé
Sauvegarder avant toute manipulation
Une sauvegarde complète (fichiers + base de données) est indispensable avant de toucher à la clé de chiffrement.
Passer en mode maintenance
Le changement de clé implique de rechiffrer les données existantes en base — une opération qui doit se faire sans écriture concurrente pour éviter des lignes corrompues.
Utiliser la commande CLI officielle
La commande est bin/magento encryption:key:change — c’est le seul chemin supporté depuis la dépréciation de l’interface admin en 2.4.8. Vous pouvez vérifier qu’elle est bien disponible sur votre installation avec bin/magento list | grep encryption:key:change avant de l’exécuter.
Vider le cache
Comme après toute opération touchant à la configuration système.
Repasser en production et vérifier
Désactiver le mode maintenance, puis tester concrètement qu’un paiement enregistré ou une intégration tierce fonctionne toujours normalement.
Attention à une conséquence directe et souvent ignorée : la rotation de la clé de chiffrement invalide immédiatement toutes les sessions clients et administrateurs actives (à l’exception des utilisateurs d’intégration), qui devront se reconnecter (source : Adobe Experience League). Ce n’est pas un bug — c’est le comportement attendu, à anticiper en communiquant si besoin, ou en programmant l’opération à un horaire de faible trafic.
Le piège classique : restaurer une base sans la bonne clé
Une erreur fréquente, notamment lors d’un travail en environnement local ou de staging : copier une base de données de production sur une nouvelle installation Magento sans transférer aussi le fichier env.php d’origine. Résultat : les données chiffrées avec l’ancienne clé (tokens de paiement enregistrés, identifiants d’intégrations tierces, certains champs de configuration) deviennent totalement illisibles sur la nouvelle installation, puisque celle-ci a généré sa propre clé aléatoire à l’installation.
La règle à retenir : la clé de chiffrement doit toujours accompagner un export de base de données, exactement comme vous transféreriez un trousseau de clés avec la maison qu’il ouvre. Sans elle, les données chiffrées sont perdues — pas corrompues, perdues, puisque le chiffrement fort n’a par définition aucune porte dérobée.
FAQ
Puis-je simplement remplacer la valeur dans env.php à la main ?
Non, ce n’est pas la bonne méthode. Remplacer directement la valeur sans passer par la procédure officielle de changement de clé laisse toutes les données déjà chiffrées avec l’ancienne clé irrécupérables, puisque Magento tentera de les déchiffrer avec la nouvelle valeur. La procédure documentée par Adobe rechiffre les données existantes avec la nouvelle clé avant de finaliser le changement — c’est cette étape de rechiffrement qui rend l’opération sûre.
Que se passe-t-il si je perds définitivement la clé de chiffrement ?
Toutes les données chiffrées avec cette clé deviennent définitivement inaccessibles — un chiffrement fort par définition ne permet aucun contournement sans la clé. En pratique, cela signifie généralement que les clients devront ressaisir leurs informations de paiement, et que les intégrations avec des systèmes tiers devront être reconfigurées depuis l’interface d’administration. C’est une raison suffisante pour sauvegarder cette clé séparément, dans un gestionnaire de mots de passe sécurisé, en plus de vos sauvegardes habituelles.
À quelle fréquence faut-il changer cette clé ?
Adobe recommande de changer la clé de chiffrement régulièrement pour renforcer la sécurité, ainsi qu’à chaque fois qu’un risque de compromission est identifié (source : Adobe Experience League). En pratique : après un changement de personnel technique ayant eu accès au serveur, après toute suspicion de fuite du fichier env.php, et systématiquement après un incident de sécurité avéré sur la boutique.
Vous ne savez pas si votre clé de chiffrement a déjà été exposée ?
On audite votre configuration de sécurité — fichier env.php, historique Git, exposition aux failles connues — et on effectue la rotation de clé en toute sécurité si nécessaire.
Demander un audit de sécurité →