Sécurité · Magento 2

Sécuriser Magento 2 : les réglages de durcissement essentiels

Sécuriser Magento 2 ne demande pas d’extension miracle. La plupart des intrusions passent par des portes connues : une faille non corrigée, un mot de passe deviné, un fichier laissé en accès libre. Adobe le dit lui-même. Voici les réglages de durcissement de Magento 2, classés par ordre d’impact, avec pour chacun pourquoi il compte et comment le faire, puis les fausses bonnes idées à éviter.

Illustration : la cloche bleue de Tocsin24 sonne au-dessus d'une boutique à la porte cadenassée, protégée par un bouclier bleu, à côté d'un téléphone qui affiche un code de connexion validé.

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.php proté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.

  1. Vérifier le mode, puis passer en production si besoin. La première commande affiche le mode actuel (default, developer ou production). 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 Magento
    Mode actuel bin/magento deploy:mode:show Passage en production bin/magento deploy:mode:set production
  2. Lire et changer l’adresse de l’administration. Choisissez un mot unique, sans admin ni backend, fait de lettres, de chiffres et du caractère _ seulement. Remplacez mon_adresse_unique par le vôtre.

    Terminal, depuis le dossier de Magento
    Adresse actuelle bin/magento info:adminuri Nouvelle adresse bin/magento setup:config:set --backend-frontname="mon_adresse_unique"
  3. Vérifier que le module de double authentification est actif.

    Terminal, depuis le dossier de Magento
    bin/magento module:status Magento_TwoFactorAuth

    La réponse attendue est Magento_TwoFactorAuth : Module is enabled.

  4. 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.php aux autres utilisateurs.

    Terminal, depuis le dossier de Magento, en root
    find 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.php

    La seconde commande contrôle le résultat : env.php ne 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.

  5. Servir pub/ et contrôler les fichiers exposés. Avec Nginx, incluez le fichier nginx.conf.sample de Magento : il fixe la racine sur pub/ 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 ordinateur
    for 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"; done

    Un code 404 ou 403 est normal. Un code 200 demande d’ouvrir l’adresse pour voir ce qui est servi.

  6. Contrôler les en-têtes de sécurité.

    Terminal, depuis n'importe quel ordinateur
    curl -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, puis nginx -t avant de recharger.

  7. 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 Magento
    bin/magento encryption:key:change

    Tous les clients et administrateurs devront se reconnecter.

  8. Chercher les failles connues des extensions et bibliothèques.

    Terminal, depuis le dossier de Magento
    composer audit --locked

    La 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.

Vérifier maintenant

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.

Portrait de Cédric Michel

Cédric Michel

Cédric développe des boutiques Magento depuis 18 ans et détient la certification Adobe Commerce Developer Expert. Il a créé Tocsin24 pour surveiller la sécurité et la santé des boutiques Magento 2 et des sites WordPress.

Badge Adobe Commerce Developer Expert Adobe Commerce Developer Expert
Vérifier la certification sur le site d’Adobe

Sources

  1. Adobe : Secure your Commerce site and infrastructure (bonnes pratiques de sécurité)
  2. Adobe : authentification à deux facteurs
  3. Adobe : notes de version de Magento Open Source 2.4.0
  4. Adobe : utiliser une adresse d'administration personnalisée
  5. Adobe : afficher ou changer l'adresse de l'administration
  6. Adobe : options de `setup:config:set`
  7. Adobe : sécurité de l'administration
  8. Adobe : modes de fonctionnement de l'application
  9. Adobe : changer de mode
  10. Adobe : servir le dossier pub/ (docroot)
  11. Adobe : permissions des fichiers en développement et en production
  12. Adobe : clé de chiffrement
  13. Adobe : définir des valeurs de configuration (`config:set --lock-env`)
  14. Adobe : prévenir le clickjacking (X-Frame-Options)
  15. Adobe : Content Security Policy
  16. OWASP : HTTP Security Response Headers Cheat Sheet
  17. MDN : Strict-Transport-Security
  18. Code source de Magento : `nginx.conf.sample`
  19. Composer : commande `audit`