Signs your PrestaShop store needs a security audit (and how to self-check first)

Last updated: June 2026.

Most PrestaShop stores don't need to buy a security product. They need to know their actual exposure, and most owners genuinely don't, because nothing visibly wrong is happening. A skimmer can sit on a checkout for weeks while orders flow normally. A vulnerable module can be unpatched for years before someone scans for it. The point of a security review isn't fear; it's replacing "I think we're probably fine" with a clear, evidenced answer. This post lays out the concrete signs that warrant a closer look, and gives you a self-check you can run in about ten minutes before deciding whether you need outside help at all.

The signs that actually matter

These aren't theoretical. Each one is something we've seen turn into a real incident on real stores. Read them as risk factors, the more that apply, the more a structured audit is worth your time.

You're running an old or end-of-life PrestaShop version

PrestaShop 1.6 is long past end of life, and most of the 1.7.x branch no longer receives security fixes. Even on 8.x, an install that's a few minor versions behind can be missing patches for publicly known issues. Old core is the single biggest predictor of exposure, because attackers don't need to find a new flaw, they just scan for the ones already documented. If you can't say which exact version you're on without checking, that itself is a sign.

Your modules haven't been updated in years

This is the real attack surface on most shops. Core gets attention; third-party modules quietly rot. There's a long history here, the blockwishlist SQL injection, Smarty-based server-side template injection (SSTI) leading to remote code execution in several modules, and a steady stream of less-famous flaws. A module you installed once and forgot is a perfect entry point precisely because nobody's watching it. If your module update list shows a stack of pending updates, or modules from vendors that no longer exist, treat that as a flashing light.

Your admin is at the default path with no rate-limiting or 2FA

A back office reachable at a predictable URL, with no brute-force protection and no two-factor authentication, is an open invitation to credential-stuffing and password-guessing bots. They run constantly, and they don't need to be clever. They just need one weak or reused password from an employee account.

No WAF, and your origin IP is exposed

If your store sits directly on the open internet with no web application firewall, every malicious request reaches your application code unfiltered. Worse, if you use a CDN but your real origin IP is leaking (in DNS history, mail headers, or an old subdomain), attackers can bypass the protection entirely and hit the server directly.

Unexplained files, modified core, or admin accounts you don't recognise

Stray PHP files in the webroot, core files that differ from a clean release, or an entry in your employee list that nobody on the team created. Any one of these can mean you've already been compromised. Backdoors are designed to look boring and stay quiet, so they rarely announce themselves.

A checkout or payment form that "looks slightly off"

This is the one that costs the most. Magecart-style skimmers inject a few lines of JavaScript that quietly copy card details as customers type, then send them to an attacker's server. The page still works. The order still completes. Only the card data leaks. If your checkout feels subtly different, an extra field, a layout shift, a script you don't remember adding, take it seriously. We've written up exactly how one of these works in our anatomy of a Magecart attack on a PrestaShop skimmer piece.

No file-integrity monitoring and no off-site backups

If you have no way to detect that a file changed, you can't tell a clean store from a compromised one, and you'll usually find out from a customer or your payment processor instead. And if your only backups live on the same server (or you've never actually tested a restore), a compromise or a failed disk can end the business, not just the day.

You're storing more customer data than you need

Every extra field you retain is liability you carry. Storing full card data, keeping years of personal data with no retention policy, or logging sensitive details turns a breach from "embarrassing" into a PCI-DSS and GDPR problem with real financial and legal weight. The safest data is the data you never kept.

A 10-minute self-check

Before you ask anyone for help, including us, run this yourself. It costs nothing and tells you a lot:

• Confirm your exact PrestaShop version and check whether it's still supported. If it's 1.6.x or early 1.7.x, you already have your answer.
• Open the module update list in your back office and count the pending updates. Note any modules from vendors that have disappeared.
• List your admin employees. Look at the ps_employee table or the Team page and verify every account with back-office access is one you recognise.
• Diff your core files against a clean copy of the same PrestaShop version. Anything modified in /classes, /controllers, or the root that you didn't change deserves scrutiny.
• Sort the webroot by modification date. Recently-changed files you can't account for are the fastest way to spot a backdoor.
• Confirm your backups exist off-site and actually restore. A backup you've never tested is a hope, not a backup.

If all six come back clean, that's genuinely reassuring, and you may not need to spend a cent. If any of them make you uneasy, that uneasiness is the useful signal.

If you have shell or database access, three read-only commands

These confirm a few of the checks above and are strictly read-only, they list and compare, they change nothing. Adjust the ps_ table prefix to your own.

# 1. List every account with back-office access – look for anyone you don't recognise
SELECT id_employee, email, lastname, firstname, active, last_connection_date
FROM ps_employee
ORDER BY last_connection_date DESC;

# 2. Spot recently-modified PHP files in the webroot (a common backdoor tell)
find /path/to/your/shop -name '*.php' -mtime -30 -printf '%TY-%Tm-%Td  %p\n' \
  | sort

# 3. Confirm your stored PrestaShop version, then compare it to the supported list
mysql -e "SELECT value FROM ps_configuration WHERE name='PS_VERSION_DB';"

The employee query is the fastest way to catch a rogue admin account; an unfamiliar email or an active=1 row nobody created is a serious flag. The find command surfaces files touched in the last 30 days. Match each against work you actually did. None of these prove a compromise on their own, but anything unexplained here is exactly the "useful signal" worth escalating.

The honest part: diagnose before you buy

Here's the turn most security pitches skip. The right response to these signs is almost never "buy a product." It's "find out what's actually wrong." Sometimes the fix is configuration or hosting, a misconfigured server, a missing WAF, an exposed origin. In which case a hosting audit is the relevant step, not a module. Sometimes it's hardening: closing the admin path, adding rate-limiting and 2FA, which is where an open-code module like Security Revolution earns its place, but only once you've confirmed that's the gap. And sometimes it's a clean-up because something already got in, which is its own focused job.

That's the whole reason a security audit is worth doing first: it maps your real exposure and tells you which of those three roads you're actually on, so you don't spend money solving a problem you don't have. You start it by entering your store URL on the security audit page; a read-only readiness check runs against the URL, and only then is the audit ordered.

If handing over access makes you nervous, it should, that instinct is correct, and we built around it. The audit is performed read-only: we look, we don't write, and we never touch your customer database. We've documented exactly what that means and what we do and don't access in our store audit readiness guide, which is worth reading before you order so you know precisely what you're agreeing to. Security and performance often travel together, so if you're already mapping your store's health it's also worth a look at the wider expert services and the performance audit alongside it.

Run the ten-minute check today. If it's clean, enjoy the peace of mind, you've earned it for free. If it isn't, you now know enough to ask the right question, which is worth far more than any single product.

Frequently asked questions

Does a security audit clean up an infection, or just find it?

An audit diagnoses, it maps your exposure and tells you whether something already got in. Cleanup is a separate, focused job, because removing a backdoor safely means finding every entry point, not just the one you noticed, then closing the hole that let it in so it doesn't return. The audit is what tells you whether you need a clean-up at all, and how deep it has to go. Treat any "we'll scan and fix it in one pass" promise with caution; a quiet, persistent backdoor rarely comes out that cleanly.

I run a current PrestaShop 8 with everything updated. Do I still need an audit?

Possibly not, and that's a good position to be in. Current core plus updated modules removes the biggest, most-scanned risks. The remaining questions an audit answers are the ones updates don't cover: is your origin IP leaking behind your CDN, is the admin path brute-forceable, do you have file-integrity monitoring and a tested off-site backup, and are you retaining more customer data than you should. If the ten-minute self-check is clean on those too, you're genuinely in good shape.

Will you need my admin password or a copy of my database?

No. A security audit starts with just your store URL and runs largely outside-in. Where a check does need a look inside the back office, a read-only employee account is enough, and we never request or take a copy of your customer or order data. The full access model is in the store audit readiness guide, read it before you order so you know exactly what's involved.

How do I tell the difference between a real compromise and a false alarm in the self-check?

You often can't, on your own, and that's the honest limit of a self-check, it's built to raise flags, not to confirm them. A recently-modified file might be a legitimate update; an unfamiliar employee might be a former contractor. The self-check's job is to tell you whether to look harder. When something unexplained shows up and you can't account for it, that's the point where an outside review pays for itself, because confirming "this is fine" carries the same value as confirming "this is not."

How often should I run the self-check?

The ten-minute version is cheap enough to run quarterly, and after any big change, a PrestaShop upgrade, a new payment module, a theme swap, or staff turnover that touched admin access. The two checks worth automating rather than repeating by hand are file-integrity monitoring and tested off-site backups; once those run continuously, most of the rest is confirming nothing has drifted.

Related articles

• Is Your PrestaShop Store Slow? Measure Before You Optimize
• Is It Safe to Give a PrestaShop Auditor Access to Your Store?
• Introducing Expert Services: PrestaShop Audits Before You Buy Another Module
• How to Tell If Your PrestaShop Store Needs an SEO Audit
• PrestaShop SEO: The Complete Guide to Ranking Higher