Admin passwords and shared access
A password reused across three services, FTP access given to a provider and never revoked, an admin account created "just to help out" and forgotten: these are human flaws, not technical ones, and they’re among the easiest to fix.
A different category of flaw
SQL injections or outdated modules are flaws in the code. The ones on this page aren’t: they come from how access is created, shared, and never withdrawn. A password reused across your inbox, your host and your CMS back office means a data leak on a completely unrelated service can hand someone access to your store. FTP credentials sent by email to a provider, never revoked after the job ends, stay valid indefinitely as long as nobody remembers to change them.
This type of flaw never shows up in a vulnerability report and never carries a CVE identifier. Yet it’s one of the most direct entry points, because it doesn’t require any technical flaw at all: the attacker simply logs in, with valid credentials.
A detail few merchants know about
PrestaShop offers, directly within its installer, an option to randomise the admin folder name instead of keeping the predictable /admin path. This isn’t a third-party extension to install separately: it’s a native, documented feature offered right from the CMS installation. It obviously doesn’t replace a strong password, but it takes your back office out of the path that bots test first and with no effort, filtering out a meaningful share of the most basic automated attempts.
Practical habits to put in place
-
One unique password per service
The CMS back-office password must never be the same as your inbox, host, or any other account. A password manager can generate and store a strong, distinct password for each one.
-
Turn on two-factor authentication where it exists
Many CMS platforms and hosts offer two-factor authentication, which still protects you even if a password alone leaks elsewhere. It’s worth enabling on the most sensitive accesses: back office, hosting, database.
-
Revoke provider access once a job is done
Any FTP, SSH or admin access given to an external provider should be disabled, or its password changed, as soon as the work is finished, not only once a problem is spotted.
-
Apply the principle of least privilege
A secondary account created for a specific need, such as order management or catalogue updates, shouldn’t have super-administrator rights it doesn’t actually need.
-
Review active accounts regularly
The list of admin accounts on a CMS grows over time, with no automatic clean-up. An account forgotten for two years is still a valid way in.
Related reading
-
File permissions on shared hosting
Another flaw rooted in human oversight rather than code, tied to server configuration.
-
Check whether your site is compromised
Free checks to run before considering a paid audit.
-
Security and cleanup of a hacked site
The full service if access to your store has already been compromised.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.