The most damaging security problems are rarely dramatic. They are doors left open: an admin login anyone can find, files that were never meant to be public sitting at a predictable path. Here is how self-hosted stores leave them open, platform by platform.
When people picture an ecommerce security problem, they picture an attack. The more common reality, and the one worth measuring, is quieter: something that should be private is simply reachable. No break-in required, because nothing was locked. On self-hosted platforms, where you own the server, a surprising amount is left open, and each platform leaves open something different.
SaaS vs self-hosted: who owns the exposure
This is a self-hosted story, and the distinction matters. On Shopify and other fully hosted platforms there is no server admin on your domain and no file system you control, so this whole class of problem mostly does not exist for them. That is a real advantage of the hosted model. The flip side, which the 2026 platform benchmark covers, is that the same model hides app and API risk a scan cannot see, which is why server-side security is reported only for the platforms that have a server side: Magento, PrestaShop, and Shopware.
Everything below is about those platforms, where you own the exposure because you own the server.
It isn’t whether you have an admin panel. It’s whether its address is on a list.
Every self-hosted store has an admin panel at some URL. Whether it is exposed comes down to one thing: is that URL predictable. And in practice, predictable means already on the public lists that automated scanners work through all day. A path does not have to be the literal default to be found; it only has to be guessable, and the common defaults and the popular custom names are all on those lists.
The platforms start from very different places here, which is the part most security advice misses. Two of these exposures turned up directly in the benchmark, on Magento and on PrestaShop, with the counts below. The path habits that follow are the mechanism behind those numbers, not separate measurements: the benchmark did not score predictable admin paths across every platform.
Shopware ships the admin at a fixed, well-known path: /admin on Shopware 6, /backend on Shopware 5. These are framework routes and are commonly left unchanged, so the location is predictable by design. PrestaShop does the opposite: it generates a random admin path during installation, one of the better default-security decisions any platform here makes, because a randomized path is genuinely not on any list. Magento sits in between. It can generate a random admin path and recommends one, but in practice many stores rename it to something memorable, backend, backoffice, panel, which puts it straight back onto the list it was meant to avoid.
A predictable path is not the same as a breach. It means the login is discoverable, so it gets found and targeted by every bot looking for one, which is why an unguessable path plus a restriction on who can reach the login at all is worth the small effort. On Magento, the admin was reachable in a way the scan flagged on 4,922 stores, close to a quarter of the Magento sample. The fix is the same on every platform and is covered in the exposed admin panel guide.
Exposed sensitive files: the backups nobody meant to publish
A hidden admin does not help if the store leaks everything else. Over the life of a store, things accumulate on the server that were never meant for the public: a database backup, an old installation folder, a log, a configuration file. Each tends to sit at a guessable path, and each can hand over exactly the information an attacker would otherwise have to work for.
This is PrestaShop’s mirror image of Shopware’s problem. PrestaShop hides the admin well by default, then tends to leave the files: sensitive files of this kind were reachable on 8,682 PrestaShop stores, more than 40% of the sample. They are not placed there deliberately. They are the residue of normal work, left reachable because nobody went looking. The exposed sensitive files guide covers what to check and how to close it.
Most stores are mostly secure, which is the trap
Across the self-hosted platforms, overall security health was actually high.
| Platform | Security health | Default admin path |
|---|---|---|
| Magento 2 | 87.06% | random slug recommended, but often renamed to a guessable one |
| Shopware 6 | 86.72% | fixed and well known (/admin) |
| PrestaShop | 82.43% | randomized during installation |
| Shopify | not measured (SaaS) | no server-side admin to reach |
Most stores, on every self-hosted platform, do most things right. But exposure does not average out. A store can pass almost every security check and still have one discoverable admin or one reachable backup, and that single open door is what matters, because a door is either locked or it is not. “Mostly secure” is exactly the state in which a real hole hides, because the overall picture looks fine. Each platform just hides its hole somewhere different: Magento in an admin renamed to something guessable, PrestaShop in the files left reachable, Shopware in a login path predictable by design.
Why it stays open
The unifying reason is the same one behind most of what this benchmark found: the problem is invisible from where the owner stands. You never visit your own admin URL the way an outsider would, so you never notice it answers to anyone who asks. You do not browse to your own leftover backup file. The storefront looks perfect, sales come in, and the open door sits at an address you have no reason to type. It takes someone deliberately looking, from the outside, to find what is reachable.
What to actually check
The fix is not a security overhaul, it is closing the specific doors. In practice that means checking:
- whether your admin path is predictable, a known default or an obvious custom name, and whether access to the login is restricted at all (exposed admin panel);
- whether backups, logs, configuration, or install files are reachable from the public web (exposed sensitive files);
- whether the basic protections around all of this are in place, such as security headers and secure cookies.
The broader picture of merchant security is in the security guide; the part specific to self-hosted stores is that you own the server, so you own the doors, and the defaults do not lock all of them for you.
A scan checks these from the outside, the same way a bot would, and tells you which doors are still open, including whether your admin path is one anybody could have guessed.