Last Updated on Oct 7, 2026 by Nurul Afsar
Magento and Adobe Commerce stores are attractive targets. They handle payment details, customer accounts, and order data, and they run on a large ecosystem of extensions that vary widely in quality. Attackers know this, and automated scanners probe thousands of stores every day looking for outdated versions, exposed files, and weak admin logins.
The good news is that most successful attacks exploit problems that a routine audit would have caught. This checklist walks through 20 areas to review, grouped by where they sit in your store. You can work through it yourself, hand it to your developer, or use it to check the work of whoever currently maintains your site.
Let our Magento team audit your store
We review your code, extensions, server, and admin access, then give you a written report and fix what we find.
Book a Magento security auditHow to use this checklist
Go through the items in order, and note each one as pass, fail, or unknown. Treat “unknown” as a fail until you can confirm it. Do the work on a staging copy first where a change could affect checkout, and take a full backup of files and database before you touch anything on production.
Part 1: Versions and patching
1. Confirm your Magento version and patch level
Start by finding out exactly what you are running. Check the version in the admin footer or with bin/magento --version, then compare it with the current supported releases listed by Adobe. Versions that no longer receive security updates cannot be made safe by other measures alone, and that includes Magento 1, which has been unsupported for years.
2. Apply security patches quickly
Adobe publishes security bulletins and patches, and some of them fix vulnerabilities that attackers begin exploiting within days. The CosmicSting vulnerability (CVE-2024-34102) in 2024 is a well-known example of a critical flaw that was widely targeted soon after disclosure. Check that every available security patch for your version is installed, and set a rule for how fast critical patches get applied.
3. Check PHP and server software versions
Your PHP version must be one that your Magento release supports and that still receives security fixes. Do the same for your web server, operating system, and database. An old PHP version is a common finding in audits, because upgrading it can break older extensions and so it keeps getting postponed.
4. Make sure supporting services are not exposed
MySQL, Redis, OpenSearch or Elasticsearch, and RabbitMQ should never answer requests from the open internet. Check which ports are reachable from outside your network, and restrict these services to localhost or a private network. Exposed search and cache servers have repeatedly led to data leaks.
Part 2: Admin access and accounts
5. Change the default admin URL
Moving the admin away from /admin will not stop a determined attacker, but it removes you from the easiest automated attacks. Confirm that the admin path is custom and that it is not mentioned anywhere public, such as in a robots.txt file.
6. Enforce two-factor authentication
Two-factor authentication is built into current Magento releases, and it should be on for every admin account without exceptions. Check that no user has been excluded and that backup codes are stored securely. Stolen or guessed admin passwords are one of the most common ways attackers get in.
7. Audit admin users and roles
Open the admin user list and look for accounts you do not recognize, former staff and contractors who still have access, and shared logins. Review roles so that each person has only the permissions their job requires. A support agent rarely needs access to system configuration or to install extensions.
8. Review API integrations and tokens
List every integration, API token, and OAuth connection. Remove the ones tied to tools you no longer use, and rotate keys for any that were shared with agencies or freelancers. Each token with broad permissions is effectively another admin password that people tend to forget about.
Part 3: Server and file system
9. Check file permissions and ownership
Writable code directories are a gift to attackers. In production, application code should be read-only for the web server user, with write access limited to the directories that truly need it, such as var, pub/media, and generated. Look for files that are world-writable, and confirm the web server does not run as a privileged user.
10. Look for exposed sensitive files
Search for files that should never be reachable by browser: app/etc/env.php, .git folders, database dumps, old backups, phpinfo() pages, and log files under var. Request them from outside the server to confirm they return an error, and remove anything that does not belong in the web root.
11. Run in production mode
A store left in developer or default mode can display detailed errors and file paths to visitors. Confirm the deploy mode with bin/magento deploy:mode:show and make sure error display is off. Error messages should be logged, not shown to customers.
12. Enforce HTTPS and security headers
Every page should load over HTTPS with a valid, current certificate, and HTTP requests should redirect. Add HSTS, and review headers such as X-Frame-Options, X-Content-Type-Options, and Referrer-Policy. Magento’s secure cookie settings should also be enabled so that session cookies are not sent over plain connections.
Part 4: Extensions and code
13. Build an extension inventory
List every installed extension, its version, its vendor, and the date it was last updated. Many stores discover modules nobody remembers installing. Disable and remove any that are unused, because unused code is still attack surface.
14. Check third-party code for known vulnerabilities
Compare your inventory against vendor release notes and public vulnerability databases. Pay special attention to abandoned extensions, which will never receive a fix, and to anything installed from a source other than the official marketplace or a trusted vendor. Where you rely on Composer, run an audit on your dependencies as well.
15. Look for modified or unexpected files
Compare your core files and vendor directory against a clean install of the same version, and review recently changed files in the codebase. Webshells often hide in places like pub/media, with innocent-looking names or double extensions. A file integrity monitoring tool makes this check continuous instead of occasional.
Part 5: Payment pages and customer data
16. Review scripts on checkout and payment pages
Card-skimming attacks, often called Magecart attacks, work by injecting JavaScript into the checkout page. Inventory every script that loads on payment pages and confirm that each one is authorized and necessary. PCI DSS 4.0.1 includes requirements for managing payment page scripts and detecting unauthorized changes, so this check also supports compliance. A strict Content Security Policy is a strong control here.
17. Search the database for injected code
Attackers frequently hide malicious JavaScript in the database rather than in files, so a file scan alone will miss it. Check CMS blocks and pages, the design configuration for custom head or footer HTML, and tracking-script fields in the system configuration. Look for obfuscated code, unfamiliar external domains, and anything referencing payment form fields.
18. Protect customer accounts
Turn on CAPTCHA for login, registration, password reset, and contact forms. Apply rate limits and lockouts for repeated failed logins, and require strong passwords. Credential-stuffing attacks reuse passwords leaked from other sites, and they can succeed even when Magento itself is fully patched.
Part 6: Monitoring and recovery
19. Put a web application firewall in front of the store
A WAF filters out common attack traffic, blocks malicious bots, and can buy you time when a new vulnerability is announced before you have patched it. Confirm that your firewall rules cover the admin, the REST and GraphQL APIs, and the checkout. A WAF supplements patching and does not replace it.
20. Verify logging, alerts, and tested backups
You cannot respond to what you cannot see. Confirm that admin actions, failed logins, and server errors are logged and that someone receives alerts for unusual activity, such as a new admin user or a changed file. Then test your backups: restore one to a separate environment and check that the store works. A backup that has never been restored is only a hope.
How to prioritize what you find
Not every failed item carries the same urgency. Use this order as a guide:
- Fix immediately: unsupported Magento or PHP versions, missing critical security patches, exposed database or search services, signs of compromise, and admin accounts without two-factor authentication.
- Fix this month: extension cleanup, permission problems, exposed backup or log files, and missing security headers.
- Schedule ongoing: monitoring, dependency reviews, quarterly user audits, and restore tests for backups.
If you find signs that the store has already been compromised, such as unknown admin users, modified files, or strange scripts in the checkout, do not simply delete them. Take the affected area offline if you can, preserve logs, change all credentials, and bring in someone experienced with Magento malware cleanup. Removing the visible code without closing the original entry point usually leads to reinfection.
How often should you audit?
A full audit once a year is a reasonable minimum, with a lighter review each quarter and an immediate check after any major upgrade, new extension, change of hosting, or change of developer. Anything that adds code or access to your store can change your risk profile, so audits should follow changes, not only the calendar.
When to bring in a professional
Some of these checks are quick, while others require tools and experience that most merchants and small teams do not have in-house. Database scanning, file comparison against clean releases, server hardening, and Content Security Policy configuration are all areas where mistakes can break checkout or leave real gaps. A specialist can also tell you which findings matter for your store and which are noise.
A professional audit should give you a written report with prioritized findings, clear remediation steps, and a plan for ongoing patching and monitoring. If you would rather not do this yourself, Numinix can audit your Magento store and handle the fixes, whether you need a one-time review, an upgrade, or ongoing security maintenance.
Magento security rarely comes down to one dramatic mistake. It comes down to a long list of small gaps that nobody was responsible for checking: a missed patch, an old admin account, an extension nobody updated, a script nobody reviewed. A regular audit closes those gaps before someone else finds them.
Use this checklist as a starting point, keep a record of what you check each time, and treat every failed item as a task with an owner and a deadline. If you need help with any of it, you can hire the Numinix team to take the whole audit off your hands.