Magento 2 security audit: a 10-point checklist

In short

A Magento 2 security audit checks ten points: version, patches, extensions, accounts, two-factor authentication, admin panel, exposed files, code integrity, backups and logs.
Four points can be checked without a terminal, from the Magento admin panel.
An audit is not a one-off event: each point has its own pace, from every deployment to every quarter.
The most often forgotten point: a backup that has never been restored is not a safe backup.

Contents

What a Magento 2 security audit covers

Adobe’s own finding: most compromised stores are breached through known, unpatched vulnerabilities, weak passwords and wrong file permissions. So an audit checks these known doors first, before looking any further.

This checklist covers the store and its server. It does not replace a penetration test, nor the analysis of a store that has already been hacked: in that case, follow what to do after a hack.

Adobe also offers a free tool, the Security Scan Tool, from your Commerce or Magento account: it scans the store from the outside, on demand or every day or week, and keeps a history of the reports.

The 10-point Magento security checklist

1. The Magento version is still supported

Why. A version that is out of support no longer gets security patches, even for a critical vulnerability.

How to check. Read the version at the bottom of any admin page (“Magento ver. 2.4.8-p5”, for example), then compare it with Adobe’s schedule. Do the same for PHP, which Adobe does not patch: PHP 8.2, for example, gets no more security fixes after 31 December 2026.

What is normal. Version 2.4.7, 2.4.8 or 2.4.9 for Magento Open Source, on its latest -pN release. The exact dates are in our article on Adobe security patches.

How often. Every month, with the end-of-support date in your diary a year ahead.

2. Security patches are applied

Why. Adobe releases isolated security patches every month, on the second Tuesday. They do not change the version number: a store can be “up to date” on paper and exposed in reality.

How to check. Ask your developer for the report from Adobe’s tool, php vendor/bin/patch-status. The full method is in our guide to Adobe patches.

What is normal. No missing patches (missing_patches empty) and no VULNERABLE entry.

How often. Every month, after the second Tuesday. Straight away for a priority 1 bulletin.

3. Extensions are useful, maintained and free of known vulnerabilities

Why. Adobe’s bulletins do not cover third-party extensions. Each one is more code and one more vendor to keep track of; Adobe recommends keeping their number down.

How to check. List the enabled modules, spot the ones no longer used, and look for security advisories published for the installed packages (commands further down).

What is normal. Every extension has a reason to be there and a vendor that still releases updates. composer audit reports nothing, or every advisory has been dealt with.

How often. Every month, and before every new installation.

4. Admin accounts and integrations are all known

Why. An attacker who gets in often creates a way back: an admin account or an integration.

How to check. System > Permissions > All Users for the accounts, User Roles for the permissions, System > Extensions > Integrations for API access. The details are in spotting a suspicious admin account.

What is normal. One named account per person, with the most limited role possible. No accounts left from former staff or a former agency. No unknown integrations.

How often. Every month, and whenever an employee or a contractor leaves.

5. Two-factor authentication is on for everyone

Why. With it, a stolen password is not enough to get into the admin panel. Adobe lists it among its priority recommendations.

How to check. At login, Magento must ask for a one-time code after the password. The methods are under Stores > Settings > Configuration > Security > 2FA.

What is normal. It has been on by default since Magento 2.4.0. Adobe strongly advises against turning it off. No account is exempt.

How often. Every quarter, and whenever an account is created.

6. The admin panel is protected

Why. The admin panel is the most targeted entry point. Adobe recommends a unique address, strict session and lockout settings and, where possible, access restricted to certain IP addresses or to a VPN.

How to check. The admin address must be neither /admin nor /backend. Under Stores > Settings > Configuration > Advanced > Admin > Security: Add Secret Key to URLs set to Yes, Admin Account Sharing set to No, and a value for the number of failed attempts before lockout (six by default; empty means unlimited).

What is normal. All these settings in place, plus a reCAPTCHA on the login page. The details are in Magento 2 security hardening.

How often. Every quarter.

7. Production mode is on and no sensitive file is exposed

Why. In developer mode, Magento shows its errors to visitors. And if the site is served from the Magento root folder instead of pub/, files such as app/etc/env.php can be read from a browser. Adobe also requires that no log, .git folder, database backup or phpinfo file be reachable.

How to check. The mode with bin/magento deploy:mode:show; the files and the security headers with curl (commands further down).

What is normal. production mode. A 404 or 403 code for every sensitive path. The Strict-Transport-Security, X-Frame-Options and X-Content-Type-Options headers present.

How often. After every deployment, and after any change of server or hosting provider.

8. The code has not been modified and stays read-only

Why. A backdoor or a card skimmer hides in a modified code file. Adobe recommends removing write access to the code and configuration in production.

How to check. If the code is under version control, git status lists the files changed since the last deployment. Also check the permissions of app/etc/env.php: other users on the server must not be able to read it. To go further: finding a skimmer in Magento.

What is normal. No file changed outside a known deployment. env.php with no permissions for “others”.

How often. Every week, and after every deployment.

9. Backups exist and can be restored

Why. After an intrusion or a mistake, the backup is the last resort. It still has to work. The CNIL, the French data protection authority, lists never checking your backups, and finding out they are unusable on the day you need them, among the mistakes to avoid.

How to check. Ask your hosting provider or your developer: when was the last test restore, and how long did it take? The CNIL recommends frequent backups, at least one in a geographically separate location, at least one offline, protected like the original data, and regular restore tests. The backup tool built into Magento has been deprecated since version 2.3.0: Adobe recommends other tools.

What is normal. The database and the files (including pub/media) backed up every day, a copy off the server and offline, and a recent successful test restore on a copy of the store.

How often. A test restore every quarter, and before every major update.

10. Logs are kept and read

Why. Logs tell you what happened: recurring errors, logins, attacks. Without them, there is no way to understand an intrusion. Badly managed, they can also fill up the disk.

How to check. Look at the size of the files in var/log and the last lines of exception.log. Check that log rotation is in place: Magento 2 log rotation.

What is normal. Files of a reasonable size, archived every night, kept long enough for an investigation, and no error repeated thousands of times.

How often. Every week.

The Magento security audit schedule

How often	Points to check
After every deployment	7. Mode and exposed files · 8. Modified code and permissions
Every week	8. Modified code · 10. Logs
Every month	1. Version · 2. Patches (after the second Tuesday) · 3. Extensions · 4. Accounts
Every quarter	5. Two-factor authentication · 6. Admin settings · 9. Test restore
Straight away	Priority 1 bulletin · an employee or contractor leaving

You run the store: what you can check yourself

Without a terminal, from the admin panel, you can check four points:

The version, at the bottom of every page (point 1).
Accounts and integrations (point 4).
Two-factor authentication: were you asked for a code when you logged in? (point 5)
The admin settings and the admin address (point 6).

For the other six, send this message to whoever manages your server.

Message to your agency or developer

Hello,

We are reviewing the security of our Magento store. Could you answer the following points?

Our Magento and PHP versions, and how long they are supported.
The report from Adobe’s tool “php vendor/bin/patch-status”: patches applied and missing.
The list of installed extensions, the ones no longer used, and the output of “composer audit”.
The Magento mode (“bin/magento deploy:mode:show”) and confirmation that the site is served from the pub/ folder.
The code files changed since the last deployment, and the permissions of app/etc/env.php.
The date of the last test restore of our backups, and where the copies are kept.

Thank you.

You manage the server: the audit commands

The bin/magento, composer and git commands are run from the Magento folder, here /var/www/store. None of them changes the store.

Version and patches (points 1 and 2):

Terminal, from the Magento folder

Magento version bin/magento --version Command-line PHP version php -v Adobe monthly patches php vendor/bin/patch-status

The command-line PHP version can differ from the web server’s: check both.
Extensions (point 3): the enabled modules, then the security advisories for the packages installed with Composer.

Terminal, from the Magento folder

bin/magento module:status --enabled composer audit --locked
Accounts (point 4): the read-only SQL queries are in spotting a suspicious admin account.
Mode and admin panel (points 6 and 7):

Terminal, from the Magento folder

Mode: production expected bin/magento deploy:mode:show Admin address bin/magento info:adminuri Two-factor authentication module bin/magento module:status Magento_TwoFactorAuth
Exposed files and headers (point 7), from any computer (replace the address with your store’s):

Terminal, from any computer

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)'
Code and permissions (point 8): files changed since the last deployment if the code is under version control, permissions of env.php, and world-writable files.

Terminal, from the Magento folder

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

The last command must print nothing. It skips pub/media, which can be very large.
Logs (point 10): file sizes and latest errors.

Terminal, from the Magento folder

ls -lh var/log/ tail -n 50 var/log/exception.log

Tocsin24 does part of this audit for you, every day

To start with, the free quick audit looks at your store from the outside, with nothing to install and just a free account: whether the version is still maintained, HTTPS certificate and redirect, response time, security headers and the number of sensitive pages exposed. These are passive checks, just like a browser visit.

With the module installed, Tocsin24 continuously monitors several points on this list. Support status of your version, missing Adobe patches and known vulnerabilities of your version (points 1 and 2), based on the patches declared on the server. New admin accounts, new integrations and their access tokens (point 4). Exposed sensitive files, every day (point 7). Code files modified outside a deployment and dropped files (point 8). Log size and disk space (point 10). Tocsin24 does not check your backups, two-factor authentication or admin settings, and does not continuously track the Magento mode or the security headers: those points remain your responsibility. And for a full assessment, the security review starts from these findings and adds manual checks.

Try it for free See Magento 2 monitoring

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

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'

Application screens with example values.

Frequently asked questions

What is a Magento security audit?

It is a methodical check of everything that exposes a store: version and patches, extensions, accounts, admin settings, exposed files, code integrity, backups and logs. It tells you what is in place, what is missing and in which order to fix things.

How often should I audit a Magento 2 store?

Each point has its own pace: exposed files after every deployment, patches and accounts every month, two-factor authentication and a test restore of the backups every quarter. A priority 1 security bulletin is dealt with straight away.

Can I audit my Magento store without technical skills?

Partly. From the admin panel, you can check the version, the accounts and integrations, two-factor authentication and the admin security settings. The rest is a question for whoever manages the server, using the ready-to-copy message in this article.

Is there a free tool to audit Magento?

Adobe offers the Security Scan Tool, free from your Commerce or Magento account, which scans the store from the outside. The Tocsin24 free audit also gives you a first free report in a few seconds, with a free account.

Is a security audit enough to protect a Magento store?

No. An audit is a snapshot. Patches come out every month, and accounts and code change: security has to be followed over time, with the schedule in this article or with continuous monitoring.

Cédric Michel

Cédric has been building Magento stores for 18 years and holds the Adobe Commerce Developer Expert certification. He created Tocsin24 to monitor the security and health of Magento 2 stores and WordPress sites.

Adobe Commerce Developer Expert
Verify the certification on Adobe’s website