Essai gratuit
FR

Sécurité · Magento 2

Audit de sécurité Magento 2 : la liste de contrôle en 10 points

Votre boutique Magento 2 est-elle protégée ? Sans audit de sécurité, personne ne peut vraiment répondre. Voici une liste de contrôle en 10 points, pensée pour être suivie. Pour chaque point : pourquoi il compte, comment le vérifier, ce qui est normal et à quel rythme le refaire. Certains points se vérifient depuis l’administration, sans compétence technique. Les autres sont pour la personne qui gère le serveur.

Cédric Michel, développeur Magento certifié Adobe Publié le Lecture : 12 min
Illustration : la cloche bleue de Tocsin24 sonne au-dessus d'une liste de contrôle aux cinq lignes cochées, devant laquelle une loupe bleue examine une petite boutique.

En bref

  • Un audit de sécurité Magento 2 vérifie dix points : version, correctifs, extensions, comptes, double authentification, administration, fichiers exposés, intégrité du code, sauvegardes et logs.
  • Quatre points se vérifient sans terminal, depuis l’administration de Magento.
  • Un audit n’est pas un événement unique : chaque point a son rythme, du déploiement au trimestre.
  • Le point le plus souvent oublié : une sauvegarde jamais restaurée n’est pas une sauvegarde sûre.
Sommaire

Ce que couvre un audit de sécurité Magento 2

Adobe le constate : la plupart des boutiques compromises le sont par des failles connues non corrigées, des mots de passe faibles et de mauvaises permissions sur les fichiers. Un audit vérifie donc d’abord ces portes connues, avant de chercher plus loin.

Cette liste porte sur la boutique et son serveur. Elle ne remplace pas un test d’intrusion, ni l’analyse d’une boutique déjà piratée : dans ce cas, suivez la marche à suivre après un piratage.

Adobe propose aussi un outil gratuit, le Security Scan Tool, depuis votre compte Commerce ou Magento : il analyse la boutique de l’extérieur, à la demande ou chaque jour ou chaque semaine, et garde l’historique des rapports.

La liste de contrôle de sécurité Magento en 10 points

1. La version de Magento est encore prise en charge

Pourquoi. Une version hors support ne reçoit plus de correctifs de sécurité, même pour une faille critique.

Comment vérifier. Lisez la version en bas de n’importe quelle page de l’administration (« Magento ver. 2.4.8-p5 », par exemple), puis comparez-la au calendrier d’Adobe. Faites de même pour PHP, qu’Adobe ne corrige pas : PHP 8.2, par exemple, ne reçoit plus de correctifs de sécurité après le 31 décembre 2026.

Ce qui est normal. Une version 2.4.7, 2.4.8 ou 2.4.9 pour Magento Open Source, à sa dernière version -pN. Les dates exactes sont dans notre article sur les correctifs de sécurité Adobe.

Rythme. Chaque mois, et la fin de prise en charge à noter dans l’agenda un an à l’avance.

2. Les correctifs de sécurité sont appliqués

Pourquoi. Adobe publie des correctifs de sécurité isolés chaque mois, le deuxième mardi. Ils ne changent pas le numéro de version : une boutique peut être « à jour » sur le papier et exposée en réalité.

Comment vérifier. Demandez à votre prestataire le rapport de l’outil d’Adobe, php vendor/bin/patch-status. La méthode complète est dans notre guide des correctifs Adobe.

Ce qui est normal. Aucun correctif manquant (missing_patches vide) et aucune faille VULNERABLE.

Rythme. Chaque mois, après le deuxième mardi. Tout de suite pour un bulletin de priorité 1.

3. Les extensions sont utiles, suivies et sans faille connue

Pourquoi. Les bulletins d’Adobe ne couvrent pas les extensions tierces. Chacune est du code de plus et un éditeur de plus à suivre ; Adobe recommande d’en limiter le nombre.

Comment vérifier. Listez les modules actifs, repérez ceux qui ne servent plus, et cherchez les avis de sécurité publiés pour les paquets installés (commandes plus bas).

Ce qui est normal. Chaque extension a une raison d’être et un éditeur qui publie encore des mises à jour. composer audit ne signale rien, ou chaque avis a une réponse.

Rythme. Chaque mois, et avant chaque nouvelle installation.

4. Les comptes administrateurs et les intégrations sont connus

Pourquoi. Un attaquant qui entre se crée souvent un accès pour revenir : un compte administrateur ou une intégration.

Comment vérifier. Système > Permissions > Tous les utilisateurs pour les comptes, Rôles utilisateurs pour les droits, Système > Extensions > Intégrations pour les accès à l’API. Le détail est dans repérer un compte administrateur suspect.

Ce qui est normal. Un compte par personne, nommé, avec le rôle le plus limité possible. Aucun compte d’ancien salarié ou d’ancienne agence. Aucune intégration inconnue.

Rythme. Chaque mois, et à chaque départ d’un salarié ou d’un prestataire.

5. La double authentification est active pour tous

Pourquoi. Avec elle, un mot de passe volé ne suffit pas pour entrer dans l’administration. Adobe la place dans ses recommandations prioritaires.

Comment vérifier. À la connexion, Magento doit demander un code à usage unique après le mot de passe. Les méthodes sont dans Magasins > Paramètres > Configuration > Sécurité > 2FA.

Ce qui est normal. Elle est activée par défaut depuis Magento 2.4.0. Adobe déconseille fortement de la désactiver. Aucun compte n’y échappe.

Rythme. Chaque trimestre, et à chaque création de compte.

6. L’administration est protégée

Pourquoi. L’administration est la porte d’entrée la plus visée. Adobe recommande une adresse unique, des réglages de session et de verrouillage stricts et, si possible, un accès limité à certaines adresses IP ou à un VPN.

Comment vérifier. L’adresse de l’administration ne doit être ni /admin ni /backend. Dans Magasins > Paramètres > Configuration > Avancé > Administration > Sécurité : Ajouter une clé secrète aux URLs sur Oui, Partage de Compte admin sur Non, un nombre d’échecs avant blocage renseigné (six par défaut ; vide veut dire illimité).

Ce qui est normal. Tous ces réglages en place, et un reCAPTCHA sur la page de connexion. Le détail est dans sécuriser Magento 2.

Rythme. Chaque trimestre.

7. Le mode production est actif et aucun fichier sensible n’est exposé

Pourquoi. En mode développeur, Magento affiche ses erreurs aux visiteurs. Et si le site est servi depuis le dossier racine de Magento au lieu de pub/, des fichiers comme app/etc/env.php peuvent être lus depuis un navigateur. Adobe demande aussi qu’aucun journal, dossier .git, sauvegarde de base ou fichier phpinfo ne soit accessible.

Comment vérifier. Le mode avec bin/magento deploy:mode:show ; les fichiers et les en-têtes de sécurité avec curl (commandes plus bas).

Ce qui est normal. Mode production. Un code 404 ou 403 pour chaque chemin sensible. Les en-têtes Strict-Transport-Security, X-Frame-Options et X-Content-Type-Options présents.

Rythme. Après chaque déploiement, et après chaque changement de serveur ou d’hébergeur.

8. Le code n’a pas été modifié et reste en lecture seule

Pourquoi. Une porte dérobée ou un skimmer de carte bancaire se cache dans un fichier de code modifié. Adobe recommande, en production, de retirer le droit d’écriture sur le code et la configuration.

Comment vérifier. Si le code est versionné, git status liste les fichiers modifiés depuis le dernier déploiement. Vérifiez aussi les droits de app/etc/env.php : il ne doit pas être lisible par les autres utilisateurs du serveur. Pour aller plus loin : chercher un skimmer dans Magento.

Ce qui est normal. Aucun fichier modifié hors d’un déploiement connu. env.php sans droit pour « les autres ».

Rythme. Chaque semaine, et après chaque déploiement.

9. Les sauvegardes existent et se restaurent

Pourquoi. Après une intrusion ou une erreur, la sauvegarde est le dernier recours. Encore faut-il qu’elle marche. La CNIL range parmi les erreurs à éviter de ne jamais vérifier ses sauvegardes et de découvrir qu’elles sont inutilisables le jour où on en a besoin.

Comment vérifier. Demandez à votre hébergeur ou à votre prestataire : quand a eu lieu la dernière restauration d’essai, et combien de temps elle a pris ? La CNIL recommande des sauvegardes fréquentes, au moins une sur un site géographiquement distinct, au moins une hors ligne, protégées comme les données d’origine, et des tests de restauration réguliers. L’outil de sauvegarde intégré à Magento est obsolète depuis la version 2.3.0 : Adobe conseille d’autres outils.

Ce qui est normal. La base et les fichiers (dont pub/media) sauvegardés chaque jour, une copie hors du serveur et hors ligne, et une restauration d’essai réussie récemment, sur une copie de la boutique.

Rythme. Une restauration d’essai chaque trimestre, et avant chaque grosse mise à jour.

10. Les logs sont gardés et lus

Pourquoi. Les journaux disent ce qui s’est passé : erreurs qui se répètent, connexions, attaques. Sans eux, impossible de comprendre une intrusion. Mal gérés, ils peuvent aussi remplir le disque.

Comment vérifier. Regardez la taille des fichiers de var/log et les dernières lignes de exception.log. Vérifiez qu’une rotation est en place : rotation des logs Magento 2.

Ce qui est normal. Des fichiers de taille raisonnable, archivés chaque nuit, gardés assez longtemps pour une enquête, et pas d’erreur qui se répète des milliers de fois.

Rythme. Chaque semaine.

Le calendrier de l’audit de sécurité Magento

Rythme Points à vérifier
Après chaque déploiement 7. Mode et fichiers exposés · 8. Code modifié et droits
Chaque semaine 8. Code modifié · 10. Logs
Chaque mois 1. Version · 2. Correctifs (après le deuxième mardi) · 3. Extensions · 4. Comptes
Chaque trimestre 5. Double authentification · 6. Réglages de l’administration · 9. Restauration d’essai
Tout de suite Bulletin de priorité 1 · départ d’un salarié ou d’un prestataire

Vous gérez la boutique : ce que vous pouvez vérifier vous-même

Sans terminal, depuis l’administration, vous pouvez vérifier quatre points :

  1. La version, en bas de chaque page (point 1).
  2. Les comptes et les intégrations (point 4).
  3. La double authentification : vous a-t-on demandé un code à la connexion ? (point 5)
  4. Les réglages de l’administration et son adresse (point 6).

Pour les six autres, envoyez ce message à la personne qui gère votre serveur.

Message à votre agence ou à votre prestataire

Bonjour,

Nous faisons le point sur la sécurité de notre boutique Magento. Pouvez-vous nous répondre sur ces points ?

  1. Notre version de Magento et de PHP, et jusqu’à quand elles sont prises en charge.
  2. Le rapport de l’outil d’Adobe « php vendor/bin/patch-status » : correctifs appliqués et manquants.
  3. La liste des extensions installées, celles qui ne servent plus, et le résultat de « composer audit ».
  4. Le mode de Magento (« bin/magento deploy:mode:show ») et la confirmation que le site est servi depuis le dossier pub/.
  5. Les fichiers de code modifiés depuis le dernier déploiement, et les droits de app/etc/env.php.
  6. La date de la dernière restauration d’essai de nos sauvegardes, et où sont gardées les copies.

Merci.

Vous gérez le serveur : les commandes de l’audit

Les commandes bin/magento, composer et git se lancent depuis le dossier de Magento, ici /var/www/boutique. Aucune ne modifie la boutique.

  1. Version et correctifs (points 1 et 2) :

    Terminal, depuis le dossier de Magento
    Version de Magento bin/magento --version Version de PHP en ligne de commande php -v Correctifs mensuels d'Adobe php vendor/bin/patch-status

    La version de PHP en ligne de commande peut différer de celle du serveur web : vérifiez les deux.

  2. Extensions (point 3) : les modules actifs, puis les avis de sécurité des paquets installés par Composer.

    Terminal, depuis le dossier de Magento
    bin/magento module:status --enabled composer audit --locked

  3. Comptes (point 4) : les requêtes SQL en lecture seule sont dans repérer un compte administrateur suspect.

  4. Mode et administration (points 6 et 7) :

    Terminal, depuis le dossier de Magento
    Mode : production attendu bin/magento deploy:mode:show Adresse de l'administration bin/magento info:adminuri Module de double authentification bin/magento module:status Magento_TwoFactorAuth

  5. Fichiers exposés et en-têtes (point 7), depuis n’importe quel ordinateur (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 curl -sI https://www.example.com/ | grep -i -E '^(strict-transport-security|x-frame-options|x-content-type-options|content-security-policy)'

  6. Code et droits (point 8) : fichiers modifiés depuis le dernier déploiement si le code est versionné, droits de env.php, et fichiers inscriptibles par tout le monde.

    Terminal, depuis le dossier de Magento
    git status --short stat -c '%A %U:%G %n' app/etc/env.php find . -path ./pub/media -prune -o -perm -o=w -not -type l -print

    La dernière commande ne doit rien afficher. Elle écarte pub/media, qui peut être très volumineux.

  7. Logs (point 10) : taille des fichiers et dernières erreurs.

    Terminal, depuis le dossier de Magento
    ls -lh var/log/ tail -n 50 var/log/exception.log

Tocsin24 fait une partie de cet audit chaque jour, à votre place

Pour commencer, l’audit rapide gratuit regarde votre boutique de l’extérieur, sans rien installer, avec un compte gratuit : version encore maintenue, certificat et redirection HTTPS, temps de réponse, en-têtes de sécurité et nombre de pages sensibles exposées. Ce sont des contrôles passifs, comme la visite d’un navigateur.

Avec le module installé, Tocsin24 surveille en continu plusieurs points de cette liste. Le support de votre version, les correctifs Adobe manquants et les failles connues de votre version (points 1 et 2), d’après les correctifs déclarés sur le serveur. Les nouveaux comptes administrateurs, les nouvelles intégrations et leurs jetons d’accès (point 4). Les fichiers sensibles exposés, chaque jour (point 7). Les fichiers de code modifiés hors déploiement et les fichiers déposés (point 8). La taille des logs et l’espace disque (point 10). Tocsin24 ne vérifie pas vos sauvegardes, ni la double authentification, ni les réglages de l’administration, et ne suit en continu ni le mode de Magento ni les en-têtes de sécurité : ces points restent à votre charge. Et pour un état des lieux complet, le bilan de sécurité part de ces constats et y ajoute des vérifications manuelles.

Essayer gratuitement Voir la surveillance Magento 2

Audit rapide · 23 octobre 2026 à 09:00

www.example.com

Magento 2 détecté. 1 point important est à corriger rapidement, 1 autre à surveiller.

Résultat global

1 point à corriger en priorité

Le reste est correct : 4 contrôles sur 6 sans problème.

  • 1Important
  • 1À surveiller
  • 4Corrects

À corriger en priorité

Important

1 page sensible est accessible

Ce que nous avons vu. 1 fichier qui ne devrait jamais être servi est lisible par quiconque. La liste n'est pas publiée ici.

Pourquoi c'est important. Ces fichiers livrent du code, des mots de passe ou des clés : ce sont les premiers que cherchent les robots d'attaque.

Quoi faire. Avec le module installé, Tocsin24 vous donne la liste exacte et la correction de chacun. Sinon, faites vérifier la configuration du serveur web par votre hébergeur.

À surveiller

À surveiller

En-têtes de sécurité manquants (2 sur 3)

Ce que nous avons vu. Absents de la page d'accueil : Strict-Transport-Security, X-Content-Type-Options.

Pourquoi c'est important. Ces en-têtes demandent au navigateur de toujours utiliser HTTPS, de refuser l'affichage du site dans le cadre d'un autre et de ne pas deviner le type des fichiers : ils coupent court à des attaques courantes.

Quoi faire. Les ajouter dans la configuration du serveur web (Nginx : add_header) ou chez l'hébergeur.

Correct

  • Correct Magento 2.4.8 : version maintenue Correctifs de sécurité publiés jusqu'au 31 mai 2028 au moins.
  • Correct Certificat HTTPS valide Reconnu par les navigateurs, valide encore 64 jours (jusqu'au 26 décembre 2026).
  • Correct Redirection vers HTTPS en place L'adresse en http renvoie vers la version chiffrée du site.
  • Correct Temps de réponse : 0,8 s Médiane de 3 mesures de la page d'accueil, depuis la Suisse.

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

Qu’est-ce qu’un audit de sécurité Magento ?

C’est la vérification méthodique des points qui exposent une boutique : version et correctifs, extensions, comptes, réglages de l’administration, fichiers exposés, intégrité du code, sauvegardes et logs. Il dit ce qui est en place, ce qui manque et dans quel ordre corriger.

À quelle fréquence faire un audit de sécurité Magento 2 ?

Chaque point a son rythme : les fichiers exposés après chaque déploiement, les correctifs et les comptes chaque mois, la double authentification et une restauration d’essai des sauvegardes chaque trimestre. Un bulletin de sécurité de priorité 1 se traite tout de suite.

Puis-je auditer ma boutique Magento sans compétences techniques ?

En partie. Depuis l’administration, vous pouvez vérifier la version, les comptes et les intégrations, la double authentification et les réglages de sécurité de l’administration. Le reste se demande à la personne qui gère le serveur, avec le message à copier de cet article.

Existe-t-il un outil gratuit pour auditer Magento ?

Adobe propose le Security Scan Tool, gratuit depuis votre compte Commerce ou Magento, qui analyse la boutique de l’extérieur. L'audit rapide de Tocsin24 donne aussi un premier bilan gratuit en quelques secondes, avec un compte gratuit.

Un audit de sécurité suffit-il à protéger une boutique Magento ?

Non. Un audit est une photo à un instant donné. Les correctifs arrivent chaque mois, les comptes et le code changent : la sécurité se suit dans le temps, avec le calendrier de cet article ou une surveillance continue.

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 : Security Scan Tool
  3. Adobe : politique de cycle de vie et dates de fin de prise en charge
  4. Adobe : politique des correctifs de sécurité isolés mensuels
  5. Adobe : Commerce Version Tool, générer un rapport
  6. Adobe : sécurité de l'administration
  7. Adobe : notes de version de Magento Open Source 2.4.0 (double authentification par défaut)
  8. Adobe : modes de fonctionnement de l'application
  9. Adobe : servir le dossier pub/ (docroot)
  10. Adobe : permissions des fichiers en développement et en production
  11. Adobe : sauvegardes du système (fonction obsolète depuis 2.3.0)
  12. CNIL : guide de la sécurité des données personnelles, fiche 17 « Sauvegarder » (version 2024, mise à jour 2026)
  13. PHP : versions prises en charge
  14. Composer : commande `audit`
  15. OWASP : HTTP Security Response Headers Cheat Sheet