Securing Your PrestaShop Store: A Plain-English Guide for Store Owners

If you run a PrestaShop store and the word "security" makes your stomach drop a little, this guide is for you. You don't need to be a developer. You need to understand a handful of ideas well enough to make good decisions — and to know which jobs you can do yourself from the back office versus which ones to hand to a developer. That's what this is: the plain-English map of PrestaShop store security, in the order things actually matter, with each deep topic linked out to its own full guide so this page never turns into a 6,000-word wall you'll never finish.

One reframing before anything else. You are not being targeted because your store is important. You're being targeted because a bot doesn't know or care what your store is. Automated scanners crawl the entire internet looking for any WordPress, Magento, or PrestaShop install with a known weakness, the way a burglar walks down a street trying every door handle. Almost every successful attack we see traces back to a basic door left unlocked — an old version, a reused password, a nulled module — not some genius hacker. That's genuinely good news, because basic doors are ones you can lock yourself.

The mental model: layers, not a magic button

There is no single setting that "secures" a PrestaShop store, and any product that promises one is selling you something. Real security is layers: each one catches what the layer above it missed. Think of it the way you think about your physical shop — a lock on the door, plus a till you empty at night, plus insurance, plus a camera. No single thing is the answer; together they mean one failure doesn't end you.

For a PrestaShop store the layers stack roughly like this, and it helps to know which is which:

Notice that "be able to recover" is on the list. Security people have a saying: it's not if, it's when. A store that can be fully restored from a clean backup in an hour is in a completely different position from one that can't — regardless of how good its defences are. Get the recovery layer right and every other mistake becomes survivable.

Start here: the five things that stop the most attacks

If you only do five things, do these. They're listed in order of return-on-effort, and every one is something a non-technical owner can do without a developer.

1. Update PrestaShop, PHP, and your modules

This is boring and it's the single most important habit. Old software stops receiving security patches, which means known holes stay open. PrestaShop ships security fixes in minor versions — running 8.1.0 when 8.1.7 exists means you're running with publicly documented holes that bots already know how to find. Check your PHP version under Advanced Parameters → Information in the back office; if it shows an end-of-life version like 7.4, ask your host to move you up. Minor updates within the same branch (say 8.1.x to 8.1.x) are usually safe after a backup and a staging test. Modules matter just as much — a vulnerable module is the most common entry point of all.

If you're stuck on an older PrestaShop version you can't safely upgrade right now — a real situation for many established stores — there are ways to close the gaps without the upgrade. We cover them in advanced hardening for stores you can't upgrade yet.

2. Turn on two-factor authentication for every admin

PrestaShop does not provide universal built-in 2FA on 1.7/8 installs; add it with a reputable module or an external identity/security layer. It means that even if someone steals your password, they still can't log in without the code on your phone. Setup takes about five minutes with an app like Google Authenticator or Authy. Turn it on for every employee account, not just yours — an employee with a weak password and no 2FA is the weakest link, and attackers go for the weakest link every time. The full walkthrough, plus password policies for the back office, is in 2FA, password policies and admin security for PrestaShop.

3. Make sure HTTPS is actually working

Nearly every store has an SSL certificate now, but "padlock in the browser" doesn't mean "fully secure." The padlock only confirms the page itself loaded over HTTPS — it says nothing about images or scripts sneaking in over plain http:// (so-called mixed content, which browsers quietly block, breaking things with no obvious error). It also doesn't guarantee that someone typing your http:// address gets redirected to the secure version before PrestaShop even loads. Both are worth getting right. The step-by-step — from enabling SSL in Shop Parameters → General to fixing mixed content and the server-level redirect — is in how to set up SSL and HTTPS on PrestaShop.

4. One person, one account — and least privilege

Shared logins ("everyone signs in as admin") are one of the most common causes of incidents and the hardest to investigate afterwards, because you have no audit trail. You can't tell who changed a price, who deleted a product, or who exported the customer list at 2 a.m. Create an individual account for every person who needs back-office access, and use PrestaShop's permission profiles (under Advanced Parameters → Team) so each person only gets what their job needs. A customer-service rep doesn't need payment settings; a warehouse operator doesn't need employee management. This isn't bureaucracy — it limits the blast radius when one account gets compromised. Audit the list quarterly and delete accounts for people who've left.

5. Don't install software you can't trust — and remove what you don't use

Modules are the most common door attackers walk through, and a vulnerable module can be exploited even if you're not actively using it. Two rules cover most of the risk. First: only install modules from sources you trust — the official PrestaShop Addons marketplace, or established developers with real support and a track record. Nulled modules (paid modules cracked and given away free) almost always contain a backdoor; the economics make it obvious — nobody gives away paid software for free out of kindness. Second: remove modules you don't use. Not just disable — disabled modules may still leave reachable files on disk, so uninstall and delete unused modules to remove that attack surface. If you haven't used it in six months and won't, it goes.

The next layer: traffic you didn't ask for

Once the basics are locked down, the next thing most owners notice is unwanted traffic — bots hammering your login page, scrapers, spam through your contact and review forms, the occasional abusive visitor. None of this requires a developer to deal with; it's mostly configuration and the right tools.

• Bad bots and unwanted crawlers. Not all bots are bad (Google's is a bot you want), so the goal is filtering, not blanket blocking. The practical how-to is in visitor control: blocking bad bots and unwanted traffic.
• Problem individuals. When it's a specific person — a fraudster, a serial chargeback, an abusive customer — you want to capture extra info on their orders and ban by IP. Covered in customer extra info and IP bans.
• Spam on your forms. Contact forms, account registration and reviews attract bot spam. A reCAPTCHA stops the bots without making real customers jump through hoops — see reCAPTCHA for PrestaShop.
• The faceted-search "?q= flood." A more technical one worth knowing exists: aggressive crawlers can turn PrestaShop's layered-navigation filters into accidental denial-of-service load. If your store feels slow under bot traffic, read surviving the ?q= flood.

The server-level layer (where you might want help)

Some hardening lives below PrestaShop, at the level of the web server and file system. You can do this yourself, but it's the layer where it's most reasonable to ask your host or a developer if you're unsure — a wrong .htaccess rule can take a site offline.

The short version: file permissions should be 755 for directories and 644 for files, never 777, and the file holding your database password (app/config/parameters.php on PrestaShop 1.7 and 8, or config/settings.inc.php on legacy 1.6) should be locked tighter still. Your .htaccess should block direct public access to folders like /app/config/, /var/ and /vendor/, and stop PHP from executing inside upload folders — so that if something nasty does get uploaded, it can't run. PrestaShop's default .htaccess is a starting point, not a finished configuration. The full rule set, copy-pasteable, is in PrestaShop .htaccess: security and performance rules.

If you want to understand the kind of attack all this server hardening defends against — how a real-world card-skimmer actually gets onto a PrestaShop store and steals payment data — the walkthrough in anatomy of a Magecart-style attack makes the abstract concrete. It's worth reading once just so the rest of this stops feeling theoretical.

The recovery layer: backups you've actually tested

Backups aren't a security measure — they're a recovery measure, and that distinction changes how you treat them. No backup stops an attack. Good backups mean an attack doesn't end your business. Three habits separate a real backup strategy from a false sense of one:

• Automate it. Manual backups get skipped and forgotten. A nightly cron job that dumps the database and copies it off-server — somewhere a compromise of your web server can't also wipe — is the baseline.
• Test the restore. A backup you've never restored is just a file with unknown contents. Restore to a staging site once a quarter. You don't want the first restore of your life to be during a live incident.
• Keep multiple restore points. Daily for the last month, weekly for six months. Some attacks — quiet database tampering especially — aren't noticed for weeks, and you need a point from before it started.

If the worst happens

Even a well-secured store can be breached, and the wrong instinct in the first hour does real damage — people delete files (destroying the evidence they need), or try to surgically clean malware they'll never fully find. There's a correct sequence: isolate, preserve, identify the entry point, restore from a clean backup, rotate every credential, and meet your notification obligations (GDPR requires notice within 72 hours of becoming aware of a breach involving personal data). Don't try to remember it under pressure — we've written the calm, step-by-step playbook so you can follow it when it counts: what to do if your store gets hacked.

Where mypresta.rocks modules fit

Most of what's on this page costs nothing but attention — updates, 2FA, sane permissions, real backups. Where a module earns its place is in the layers that are tedious or impossible to do by hand: continuously watching your files for changes you didn't make, filtering hostile traffic in real time, and keeping cookie and consent handling correct without breaking the storefront. Our security modules exist to automate exactly those jobs so you're not doing them manually at midnight — the benefit being one less thing for a non-technical owner to monitor, and changes you'd otherwise miss surfacing on a dashboard instead of in an incident report. They're a layer on top of the free fundamentals here, not a replacement for them. Lock the free doors first; reach for tooling for the parts that genuinely need watching around the clock.

The one habit that ties it together

Security isn't a feature you switch on once and forget — it's maintenance, like keeping your catalogue accurate or your stock counts honest. The owners who stay out of trouble aren't the ones who bought the most software; they're the ones who set a recurring reminder. Once a quarter, twenty minutes: confirm PrestaShop and your modules are up to date, check that 2FA is on for everyone, remove ex-employee accounts, and — most important — verify that a backup actually restores. Twenty minutes every three months is dramatically cheaper than recovering from a breach, and it turns the whole subject from a source of dread into a routine you barely think about.

If you want the same ground covered as a tick-box list you can work straight through rather than a guided tour, the companion piece is the complete PrestaShop security hardening checklist. Start there if you already know the concepts and just want to make sure nothing's been missed.