En bref
- D’abord les correctifs de sécurité : aucun réglage ne protège une boutique qui a une faille connue.
- Ensuite l’administration : authentification à deux facteurs, adresse personnalisée, un compte par personne avec le moins de droits possible.
- Côté serveur : mode production, site servi depuis
pub/, code en lecture seule,env.phpprotégé. - Ajoutez les en-têtes de sécurité (HSTS, X-Frame-Options, X-Content-Type-Options). Et méfiez-vous des réglages copiés sans être compris.
Sommaire
Pourquoi durcir Magento 2
Adobe a observé que la plupart des boutiques compromises ne le sont pas par un attaquant génial. Les attaquants profitent surtout de failles connues non corrigées, de mots de passe faibles et de mauvaises permissions sur les fichiers.
Le durcissement ferme ces portes, une par une. Aucun réglage n’est suffisant seul : c’est leur addition qui compte. Les voici, du plus important au plus fin.
1. Appliquer les correctifs de sécurité de Magento
Pourquoi. Adobe place la mise à jour en tête de ses recommandations : c’est la protection principale contre les attaques. Une faille publiée est vite connue de tous, attaquants compris.
Comment. Restez sur une version encore prise en charge et appliquez chaque mois les correctifs de sécurité. Tout est expliqué dans notre guide : correctifs de sécurité Adobe : vérifier qu’ils sont vraiment appliqués. Abonnez-vous aussi au service de notification de sécurité d’Adobe.
2. Sécuriser l’administration de Magento 2
L’administration donne accès aux commandes, aux clients et au code des pages. C’est la cible numéro un.
Garder l’authentification à deux facteurs
Pourquoi. Avec la double authentification, un mot de passe volé ne suffit plus : il faut aussi le code du téléphone. Adobe la classe parmi ses recommandations prioritaires.
Comment. Depuis Magento 2.4.0, elle est activée par défaut : chaque administrateur la configure à sa première connexion. Adobe déconseille fortement de la désactiver. Les méthodes (Google Authenticator, Duo, Authy, clé U2F) se choisissent dans Magasins > Paramètres > Configuration > Sécurité > 2FA. Si personne ne vous a jamais demandé de code à la connexion, posez la question à votre prestataire.
Changer l’adresse de l’administration
Pourquoi. Des robots essaient les adresses courantes comme /admin ou /backend. Une adresse unique réduit cette exposition. Adobe précise que cela n’arrête pas un attaquant déterminé : c’est une couche de plus, pas une protection.
Comment. Le plus sûr est de la changer depuis le serveur (voir plus bas). L’administration le permet aussi (Magasins > Paramètres > Configuration > Avancé > Administration > URL de base de l’admin, réglage Utiliser le chemin d’accès au back office personnalisé), mais Adobe le déconseille si vous ne savez pas corriger un fichier de configuration sur le serveur : une erreur coupe l’accès, et seul le serveur permet alors de le rétablir. Vérifiez aussi avec votre hébergeur : certains pare-feux attendent l’adresse standard. Si vous le pouvez, limitez l’accès à l’administration à certaines adresses IP ou à un VPN, comme le recommande Adobe.
Régler la sécurité des comptes
Dans Magasins > Paramètres > Configuration > Avancé > Administration > Sécurité :
- Ajouter une clé secrète aux URLs : laissez Oui. C’est le réglage par défaut ; il ajoute une clé secrète aux adresses de l’administration.
- Partage de Compte admin : Non, pour qu’un compte ne serve pas sur plusieurs appareils à la fois.
- Nombre d’échecs maximum pour le verrouillage du compte : six essais par défaut. Ne laissez pas le champ vide : vide veut dire essais illimités.
- Durée de la session Admin : la durée d’une session sans activité, 900 secondes (15 minutes) par défaut.
- Expiration du mot de passe : la durée de vie des mots de passe. Adobe cite la norme PCI DSS, qui demande de les changer au moins tous les 90 jours.
Ajoutez le reCAPTCHA sur la page de connexion de l’administration, contre les essais automatiques de mots de passe. Et suivez le principe du moindre privilège : un compte par personne, avec un rôle limité à ce dont elle a besoin. Pour faire le tour des comptes : repérer un compte administrateur suspect.
3. Passer Magento en mode production
Pourquoi. En mode développeur, Magento affiche les erreurs dans le navigateur, avec des chemins de fichiers et des détails du code. En mode production, les erreurs sont écrites dans les journaux et jamais montrées aux visiteurs. Le mode production est aussi plus rapide.
Comment. Une boutique en ligne doit être en mode production. La commande est plus bas.
4. Ne servir que le dossier pub/ de Magento
Pourquoi. Magento contient des fichiers qui ne doivent jamais être lisibles depuis un navigateur : app/etc/env.php (accès à la base, clé de chiffrement), les journaux de var/log, le dossier .git, composer.json. Adobe explique que si le site est servi depuis le dossier racine de Magento, le reste des fichiers est accessible depuis un navigateur.
Comment. La racine du site web doit être le dossier pub/. C’est déjà le cas avec le fichier nginx.conf.sample fourni par Magento. Adobe demande aussi de faire le ménage : aucun fichier de log, dossier .git, sauvegarde de base ou fichier phpinfo accessible.
5. Mettre le code de Magento en lecture seule
Pourquoi. Un attaquant qui peut écrire dans le code peut y cacher une porte dérobée ou un skimmer de carte bancaire. Adobe demande, en production, de retirer le droit d’écriture sur le code et la configuration, et de rendre app/etc/env.php illisible pour les autres utilisateurs du serveur.
Comment. Adobe recommande deux utilisateurs sur un serveur dédié : un pour le serveur web, un autre pour les commandes et le cron, qui possède les fichiers. Les commandes sont plus bas. Pour une mise à jour, on rend les fichiers inscriptibles, puis on les remet en lecture seule.
6. Protéger la clé de chiffrement et la base de données de Magento
La clé de chiffrement protège les mots de passe et les données sensibles enregistrés par Magento. Adobe conseille de la changer régulièrement, et dès qu’elle a pu fuiter : après une intrusion, ou si env.php a été exposé. Depuis Magento 2.4.8, cela se fait seulement en ligne de commande. Le changement déconnecte tous les clients et administrateurs.
La base de données : Magento s’y connecte avec l’utilisateur donné à l’installation, root par défaut. La procédure d’Adobe crée un utilisateur dédié qui n’a de droits que sur la base de Magento. Ne laissez pas la boutique se connecter avec un compte qui a la main sur tout le serveur de base de données.
Les réglages sensibles : Adobe recommande de verrouiller les valeurs de configuration critiques avec bin/magento config:set --lock-env. La valeur est écrite dans app/etc/env.php et ne peut plus être changée depuis l’administration.
7. Ajouter les en-têtes de sécurité HTTP à Magento
Ce sont des consignes que le serveur envoie au navigateur avec chaque page.
| En-tête | Ce qu’il fait | Dans Magento |
|---|---|---|
Strict-Transport-Security (HSTS) |
Le navigateur n’utilise plus que HTTPS pour votre site. | Réglage Activer HTTP Strict Transport Security (HSTS) dans Magasins > Paramètres > Configuration > Général > Web > URL de base (sécurisé), ou sur le serveur web. |
X-Frame-Options |
Interdit d’afficher vos pages dans le cadre d’un autre site (clickjacking). | Envoyé par Magento, SAMEORIGIN par défaut, réglé dans app/etc/env.php. |
X-Content-Type-Options: nosniff |
Le navigateur ne devine pas le type d’un fichier : un fichier texte ne devient pas un script. | À ajouter sur le serveur web. |
Content-Security-Policy |
Liste les sources de scripts autorisées. | Depuis Magento 2.4.7, en mode restrictif sur les pages de paiement, en mode « rapport » ailleurs. |
L’OWASP recommande aussi de retirer les en-têtes qui affichent la version des logiciels, comme X-Powered-By.
8. Garder peu d’extensions Magento, et des extensions sûres
Pourquoi. Chaque extension ajoute du code, donc des failles possibles, et un éditeur de plus à suivre. Adobe recommande de limiter le nombre d’extensions et d’éditeurs.
Comment. Prenez vos extensions sur l’Adobe Commerce Marketplace ou par votre intégrateur. Désinstallez celles qui ne servent plus : une extension désactivée reste dans le code. Faites relire le code des extensions quand c’est possible, et suivez leurs mises à jour comme celles de Magento.
Ce qu’il ne faut pas faire pour sécuriser Magento
- Empiler les extensions « de sécurité ». Une extension de plus, c’est du code et un éditeur de plus. Elle ne remplace ni les correctifs, ni les réglages ci-dessus.
- Croire qu’une adresse d’administration cachée suffit. Adobe le dit : cela réduit le bruit des robots, pas le risque face à un attaquant déterminé.
- Désactiver la double authentification parce qu’elle gêne. Adobe le déconseille fortement.
- Rendre tout inscriptible pour faire disparaître une erreur de droits. En production, le code doit rester en lecture seule.
- Copier une configuration trouvée en ligne sans la comprendre. Une durée HSTS trop longue, une adresse d’administration mal changée ou une longueur minimale de mot de passe modifiée (Adobe signale des problèmes de compatibilité) peuvent couper l’accès à la boutique ou à l’administration.
- Laisser un ancien compte actif : salarié parti, ancienne agence, compte de test.
Vous gérez le serveur : durcir Magento 2 sur Debian ou Ubuntu
Les commandes bin/magento se lancent depuis le dossier de Magento, ici /var/www/boutique, avec l’utilisateur qui possède les fichiers.
-
Vérifier le mode, puis passer en production si besoin. La première commande affiche le mode actuel (
default,developerouproduction). Le passage en production compile le code et déploie les fichiers statiques : faites-le hors des heures de vente.Terminal, depuis le dossier de MagentoMode actuel bin/magento deploy:mode:show Passage en production bin/magento deploy:mode:set production -
Lire et changer l’adresse de l’administration. Choisissez un mot unique, sans
adminnibackend, fait de lettres, de chiffres et du caractère_seulement. Remplacezmon_adresse_uniquepar le vôtre.Terminal, depuis le dossier de MagentoAdresse actuelle bin/magento info:adminuri Nouvelle adresse bin/magento setup:config:set --backend-frontname="mon_adresse_unique" -
Vérifier que le module de double authentification est actif.
Terminal, depuis le dossier de Magentobin/magento module:status Magento_TwoFactorAuthLa réponse attendue est
Magento_TwoFactorAuth : Module is enabled. -
Mettre le code en lecture seule. Voici la commande d’Adobe pour deux utilisateurs, en mode production, à lancer avec les droits
root. Elle retire l’écriture au groupe du serveur web sur le code et la configuration, et retire tout accès àenv.phpaux autres utilisateurs.Terminal, depuis le dossier de Magento, en rootfind app/code lib pub/static app/etc generated/code generated/metadata var/view_preprocessed \( -type d -or -type f \) -exec chmod g-w {} + && chmod o-rwx app/etc/env.php stat -c '%A %U:%G %n' app/etc/env.phpLa seconde commande contrôle le résultat :
env.phpne doit avoir aucun droit pour « les autres », par exemple-rw-r-----. Pour une mise à jour, Adobe donne la commande inverse dans la même page. -
Servir
pub/et contrôler les fichiers exposés. Avec Nginx, incluez le fichiernginx.conf.samplede Magento : il fixe la racine surpub/et refuse les fichiers sensibles. Puis, depuis n’importe quel ordinateur, vérifiez la réponse du site pour quelques chemins (remplacez l’adresse par celle de votre boutique) :Terminal, depuis n'importe quel ordinateurfor p in /.git/HEAD /app/etc/env.php /setup/ /var/log/system.log; do printf '%s ' "$p"; curl -s -o /dev/null -w '%{http_code}\n' "https://www.example.com$p"; doneUn code 404 ou 403 est normal. Un code 200 demande d’ouvrir l’adresse pour voir ce qui est servi.
-
Contrôler les en-têtes de sécurité.
Terminal, depuis n'importe quel ordinateurcurl -sI https://www.example.com/ | grep -i -E '^(strict-transport-security|x-frame-options|x-content-type-options|content-security-policy)'Chaque en-tête présent s’affiche sur une ligne. Une réponse vide veut dire qu’aucun n’est envoyé. Avec Nginx, ajoutez par exemple
add_header X-Content-Type-Options "nosniff" always;dans le bloc du site, puisnginx -tavant de recharger. -
Changer la clé de chiffrement si elle a pu fuiter. Suivez la procédure d’Adobe : mode maintenance, cron arrêté, sauvegarde de
env.php, puis :Terminal, depuis le dossier de Magentobin/magento encryption:key:changeTous les clients et administrateurs devront se reconnecter.
-
Chercher les failles connues des extensions et bibliothèques.
Terminal, depuis le dossier de Magentocomposer audit --lockedLa commande liste les avis de sécurité publiés sur Packagist pour les paquets installés. Elle ne voit pas les extensions installées hors Composer, dans
app/code.
Tocsin24 contrôle chaque jour ce qui se voit de l’extérieur
Chaque jour, et à la demande, Tocsin24 sonde votre boutique comme le ferait un visiteur, une requête par contrôle, sans jamais tenter d’attaque. Il vérifie que ne sont pas servis : le dossier .git, .env, app/etc/env.php, app/etc/config.php, composer.json, composer.lock, auth.json, les journaux de var/log, l’assistant setup/, un fichier phpinfo.php ou .DS_Store. Un fichier n’est signalé que si son contenu est bien reconnu, pas sur un simple code 200 : un fichier exposé ouvre un incident critique, clos de lui-même quand il ne répond plus. Tocsin24 recommande aussi de désactiver le listing des dossiers et de fermer GraphQL s’il ne sert à rien sur votre boutique, et vérifie que l’intégrité du code est surveillée. Une protection qui était en place puis disparaît vous est signalée.
Pour chaque point, la page Durcissement dit ce qui a été vu, pourquoi c’est un risque, comment corriger et la commande pour vérifier. L’audit rapide gratuit contrôle de son côté HTTPS et les en-têtes HSTS, X-Frame-Options et X-Content-Type-Options. Mais la surveillance continue ne lit pas vos réglages : ni la double authentification, ni l’adresse de l’administration, ni le mode de Magento, ni les permissions des fichiers, ni les en-têtes de sécurité. Ces points restent à vérifier par vous ou par votre prestataire.
Durcissement
Ce que le serveur web ne devrait pas servir, et les protections à mettre en place : vérifié chaque jour par une sonde, depuis l'extérieur.
Fichiers et chemins exposés 1 à faire
-
À faire composer.json non servi incident
Observé : /composer.json répond 200 avec le contenu attendu d'un tel fichier : il est lisible par quiconque. (le 23 octobre 2026 à 05:20)
Pourquoi : composer.json révèle les paquets et versions exacts installés : les failles à tenter se lisent dedans.
Correction : Racine du site sur pub/ (Magento) ; sinon refuser « \.json$ » à la racine ou déplacer le projet hors du dossier servi.
curl -s -o /dev/null -w '%{http_code}\n' 'https://www.example.com/composer.json'
Écrans de l’application avec des valeurs d’exemple.
Questions fréquentes
Comment sécuriser une boutique Magento 2 ?
Dans l’ordre : appliquer les correctifs de sécurité d’Adobe, garder la double authentification, changer l’adresse de l’administration, limiter les droits des comptes, passer en mode production, servir seulement le dossier pub/, mettre le code en lecture seule et ajouter les en-têtes de sécurité.
Comment changer l’adresse de l’administration de Magento 2 ?
Sur le serveur, bin/magento setup:config:set --backend-frontname="votre_adresse", depuis le dossier de Magento. bin/magento info:adminuri affiche l’adresse actuelle. Choisissez un mot unique, ni admin ni backend. Adobe déconseille de la changer depuis l’administration sans savoir corriger la configuration sur le serveur.
Peut-on désactiver l’authentification à deux facteurs de Magento ?
C’est possible techniquement, mais Adobe le déconseille fortement. Elle est activée par défaut depuis Magento 2.4.0 et fait partie des recommandations prioritaires d’Adobe.
Comment savoir si Magento est en mode production ?
Sur le serveur, bin/magento deploy:mode:show affiche le mode actuel. En mode production, les erreurs ne sont jamais affichées aux visiteurs.
Une extension de sécurité suffit-elle à protéger Magento ?
Non. Les intrusions passent surtout par des failles non corrigées, des mots de passe faibles et de mauvaises permissions. Une extension ajoute du code de plus à surveiller. Elle ne remplace ni les correctifs, ni les réglages de base.
Sources
- Adobe : Secure your Commerce site and infrastructure (bonnes pratiques de sécurité)
- Adobe : authentification à deux facteurs
- Adobe : notes de version de Magento Open Source 2.4.0
- Adobe : utiliser une adresse d'administration personnalisée
- Adobe : afficher ou changer l'adresse de l'administration
- Adobe : options de `setup:config:set`
- Adobe : sécurité de l'administration
- Adobe : modes de fonctionnement de l'application
- Adobe : changer de mode
- Adobe : servir le dossier pub/ (docroot)
- Adobe : permissions des fichiers en développement et en production
- Adobe : clé de chiffrement
- Adobe : définir des valeurs de configuration (`config:set --lock-env`)
- Adobe : prévenir le clickjacking (X-Frame-Options)
- Adobe : Content Security Policy
- OWASP : HTTP Security Response Headers Cheat Sheet
- MDN : Strict-Transport-Security
- Code source de Magento : `nginx.conf.sample`
- Composer : commande `audit`