You get a security-scan phishing email. A customer asks if your store is "safe". Your insurer wants to know when the last penetration test happened. Do you actually know if your store is safe right now? Most merchants don't. They were told three years ago, at launch, that everything was fine. The team that told them that doesn't work there anymore.
The good news is that most Magento 2 security problems are boring to find. They aren't exotic zero-days. They're things like a database tool left visible at a predictable URL, or a checkout page that still accepts insecure connections. You can find the majority of them in ten minutes with a browser and no developer.
Key takeaway: You don't need a penetration test to know if your store is obviously broken. You need a browser, ten minutes, and the list below. Most of what we find when we open a paid security audit is on this list. If none of these are true on your store, you're in solid shape on the basics, and you can sleep fine tonight.
The 10-minute version
These are the ten things we check first on every Magento 2 store that walks in for a security audit. Most of what a paid audit surfaces in its first day sits somewhere on this list. You can work through it in a coffee break, without a developer, and without logging into anything you shouldn't.
One rule before you start: if a check below turns up something that looks wrong, don't panic-email your team. Write it down. Finish the list. Then triage the whole batch together, because what looks scariest isn't always what's most urgent. The last section of this article tells you how to sort that.
The two-minute version: use the scanner
If you want the automated version first, our security check scanner runs most of the checks below for you. Punch in your domain, wait two minutes, get a report. It's free, it doesn't require anything installed, and it hits the same things a paid audit hits first.
Everything below is what the scanner is looking for, what it means if it finds something, and the handful of checks the scanner can't do on its own (like "is there still a 2019 admin account belonging to the dev who left two years ago").
The 10 checks
-
Is a database tool publicly reachable on your domain?
Adminer and phpMyAdmin are browser-based tools that give direct access to your database. They belong on developer laptops, not on your public website. In your browser, try yourstore.com/adminer.php, yourstore.com/_db.php1, yourstore.com/phpmyadmin/, and yourstore.com/pma/. Any of them returning a login screen instead of a 404 is the single worst finding in this article. Treat it as an active incident: call your dev team now, not tomorrow. A public database tool means anyone on the internet can try to guess their way into all your customer data.
-
Is your admin URL still /admin?
Try yourstore.com/admin. It shouldn't load a login page. Magento ships with a tool to move the admin to a hard-to-guess path, and a good team always uses it. If your admin is still at /admin, you're getting hammered by automated bots trying lists of leaked passwords against your login every hour of every day, and you're relying on password strength alone to survive it.
-
Is your site's encryption up to date?
The lock icon next to your URL means your traffic is encrypted, but not all encryption is equal. Go to ssllabs.com/ssltest/ and enter your domain. You want a grade of A or A+. A B grade with a note about old protocols (TLS 1.0 or 1.1) being enabled is a payment-compliance problem under the standard your card processor audits you against (PCI-DSS), and it needs to be fixed this quarter. Anything lower than B is an emergency.
-
Does your site enforce HTTPS, including subdomains?
Type http://yourstore.com (not https) into a fresh browser tab. It should redirect to https within a second. Then open any subdomain you use (blog.yourstore.com, shop.yourstore.com) and do the same. If any subdomain loads plain HTTP, you have a session-hijacking window you don't need to have.
-
Do you have subdomains pointing at things you no longer use?
Your domain has an address book (the DNS zone) that maps names like "blog.yourstore.com" to the servers that host them. When you stop using a service (a staging host, an email tool, a marketing subdomain), the address book entry often stays behind. Ask whoever manages your DNS for the full list of entries, then try loading each subdomain in a browser. Any that returns "hostname not found" or a third-party "this site is not configured" error page is a takeover risk: someone else can claim the empty hosting slot and put their content on your domain. This is a common finding after hosting migrations.
-
Is CAPTCHA on your admin login page?
Open the admin login in a private browser window. There should be a "I'm not a robot" challenge, a grid of traffic-light images, or an invisible reCAPTCHA indicator. If the login is just a username and password with no challenge, the automated bots from check 2 have nothing slowing them down.
-
Do all admin users have two-factor authentication on?
Inside the admin panel, go to System → Permissions → All Users. Every row should show a 2FA enrolment. If any admin user, especially an owner-level one, is 2FA-off, that's a single password between your store and a takeover. Magento Open Source ships with 2FA enabled by default; disabling it is always a deliberate choice and usually the wrong one.
-
Are there admin users who shouldn't still be there?
In the same Users list, scroll through and read names. The contractor from 2022. The freelancer from last year's theme redesign. The agency account from the old support contract. Each one is an active account that can log in right now. Disable anyone who doesn't need access this week, and review the list every quarter.
-
Is your Magento version current, or a year-plus behind?
At the bottom of the admin, or in your hosting control panel, you can see the Magento version. Check it against magento.com's release notes. If you're more than one major version behind, or if your current version shows security patches you haven't applied, that's technical debt with security implications. Not an emergency, but it belongs on next quarter's roadmap.
-
Do you have a backup you've restored from recently?
The question isn't whether backups are running somewhere on a schedule. The question is: have you, or your team, successfully restored a recent backup onto a test environment in the last six months? If not, your backup status is a guess. Many "backup" setups we find have been silently failing for weeks because nobody tests them. The fix is a quarterly drill, not more backup software.
When you find something
If check 1 turns up a public database tool, that's an active incident. Send one Slack message to your dev team right now, subject line "URGENT: public database tool at [path], needs to be removed today", and don't go to lunch until it's gone. Everything else on the list can wait until tomorrow.
If checks 2 through 10 turn up one or two issues, that's expected. Most stores we audit have two or three of these. Write them down, send the list to your dev team or your agency with a "can we schedule these into the next few weeks?" note, and move on. It's normal work, not an emergency.
If checks 2 through 10 turn up six or seven issues, that's the signal you're due for a real security audit. One or two things slip through every store's maintenance; six or seven is a pattern. It means nobody has been looking at the security posture for a while, and a pattern is the kind of thing an external set of eyes finds more quickly than an internal one.
Your developer can read the technical companion to this article, which covers what each of these findings looks like in the Magento codebase and how to fix it properly.
FAQ
Ten minutes of checks turned up three things. Now what?
We do one-day Magento 2 security audits that sort your findings into "fix this week", "fix this quarter", and "document and review". You get a prioritised remediation plan with estimated effort, not a 60-page PDF nobody will read.