A PrestaShop store is a tempting target for the simple reason that it sits at the intersection of money and personal data: card flows, customer names and addresses, order history, and an admin panel that can be reached from anywhere on the internet. Most of the attacks that hit it are not clever. They are automated, indiscriminate, and looking for the one box you forgot to tick. This page is that list of boxes. It is the master checklist for hardening a PrestaShop store, ordered so the highest-payoff, lowest-effort items come first, with each deeper topic handed off to the guide that covers it properly.
Reviewed June 2026. These controls apply to PrestaShop 1.7, 8 and 9 (PS9's back office runs on Symfony 6.4); we keep this checklist current as advisories and PHP support dates move.
Use it as a checklist, not an essay. Work top-down: the items in Level 1 close the doors that automated scanners rattle every day, and you can do most of them from your back office or your hosting panel in an afternoon. If you want the same ground covered in plain language with no jargon at all, start with our plain-English guide for store owners first and come back here for the full sweep.
How to use this checklist
Each item below is a control with a clear owner and a clear payoff. Where a control is deep enough to deserve its own walkthrough, 2FA setup, .htaccess rules, SSL, blocking bots. This page gives you the one-paragraph "what and why," then links to the guide that does the step-by-step. That hub-and-spoke layout is deliberate: you get the whole map here without us re-explaining reCAPTCHA for the fifth time, and you follow the link when you're ready to actually configure something.
One framing decision before you start: most of these controls are about reducing attack surface (fewer doors), and a few are about detecting and recovering when something gets through (alarms and fire exits). A secure store needs both. A store with a 16-character admin password and no backups is one bad module update away from a very bad week.
Level 1. Essentials (do these this week)
1. Rename the admin directory
PrestaShop already ships your admin folder with a random suffix (something like admin8f3k2) for exactly this reason, but plenty of stores upgraded from older versions still sit on a guessable /admin or /adminXXXX that scanners try first. Rename the folder over FTP/SFTP or your host's file manager to something nobody will guess (avoid obvious words like backoffice, manage or panel. Those are scanned too). PrestaShop detects the rename on the next login; afterwards, update your bookmark and tell your team the new URL. So what? The single biggest source of admin brute-force traffic is bots hammering predictable login URLs. Move the door and most of them never find it.
2. Strong, unique admin passwords, and prune the account list
Every back-office account should use a long, unique password (16+ characters) generated and stored in a password manager, never reused anywhere else. Just as important: open Advanced Parameters → Team → Employees and delete every account that no longer needs access. A former freelancer's dormant admin login is pure attack surface with zero upside. While you're there, confirm nobody has quietly created an account you don't recognise.
3. Force HTTPS everywhere
Running checkout and login over plain HTTP in 2026 isn't a risk you accept, it's a defect you fix. HTTPS protects credentials, card data and personal information in transit, and PrestaShop has a built-in switch to enforce it under Shop Parameters → General → Enable SSL plus Enable SSL on all pages. If you haven't got a certificate installed and forced site-wide yet, follow our SSL and HTTPS setup guide, it covers certificate install, the two PrestaShop toggles, and fixing the mixed-content warnings that trip people up.
4. Keep PrestaShop and PHP patched
The overwhelming majority of compromised PrestaShop stores were running a version with a publicly known, already-patched vulnerability. Stay on a supported release, subscribe to PrestaShop's security advisories, and never run an end-of-life PHP build (7.4 and 8.0 are both past their security-support dates). Before any core upgrade: take a full backup, test on a staging copy, and confirm your modules are compatible. So what? Patching isn't glamorous, but "we were one version behind" is the single most common line in a breach post-mortem.
5. Reduce what your error pages and headers reveal
Make sure debug mode is off in production. Confirm _PS_MODE_DEV_ is false in config/defines.inc.php, and check Advanced Parameters → Performance → Debug mode is disabled, so a stack trace never hands an attacker your file paths, table prefix or library versions. A leaked debug page is a free map of your install.
Level 2, Access control
6. Turn on two-factor authentication for the back office
2FA means a stolen admin password alone is not enough to log in. The attacker also needs the code on your phone. This closes off credential-stuffing and phishing in one move, and it's the highest-value access control you can add. The full setup, including password policies and session hardening, is its own guide: two-factor auth, password policies and admin security for PrestaShop.
7. Rate-limit and lock out failed logins
Brute-force tools try thousands of passwords. Cap them: trigger a temporary lockout after a handful of failed attempts (a common policy is a 15-minute lock after five fails, a long lock or IP ban after twenty). PrestaShop doesn't throttle admin logins aggressively by itself, so this is typically handled at the WAF/edge or with a security module.
8. Restrict admin access by IP
If your team logs in from fixed addresses (office, home, a VPN exit), lock the admin directory to those IPs with an .htaccess rule (Require ip ... on Apache) or your firewall. This one control eliminates the bulk of brute-force and credential-stuffing traffic outright, because the attacker's requests never reach the login form. The exact rules live in our .htaccess security and performance guide.
9. Tighten employee permissions
PrestaShop's profile system under Advanced Parameters → Team → Permissions is granular, use it. A content editor doesn't need module management; a customer-service agent doesn't need server settings or SQL Manager. Give each profile the minimum it needs, then re-audit the employee list on a schedule and remove anyone who's left. Least privilege means a single compromised staff login can't burn the whole store down.
Level 3, Server and file hardening
On nginx, the equivalent is a deny rule for sensitive application folders and uploaded PHP. Paths vary by hosting layout, so test with nginx -t and a staging request first.
location ~* ^/(app|var|vendor|config|classes|controllers|override)/ {
deny all;
}
location ~* /(img|upload)/.*\.php$ {
deny all;
}
Server rules and security headers should be checked together after hardening.
10. Set correct file permissions
Directories should be 755, files 644. Nothing in a PrestaShop install should ever be 777 (world-writable), if a tutorial tells you to chmod 777 to "make it work," that tutorial is the problem. World-writable files are exactly what a file-upload exploit needs to drop a backdoor.
11. Block direct web access to sensitive directories
Several PrestaShop folders should never be reachable from a browser: /app/, /cache/, /config/, /var/, /vendor/, /translations/, /mails/ and the like. PrestaShop's shipped .htaccess covers some of these, but verify them and add what's missing (and confirm Options -Indexes is set so directory listing is off, which otherwise leaks your exact module list to anyone curious). The complete rule set, sensitive directories, listing, dotfiles, is in the .htaccess security and performance guide.
12. Add HTTP security headers
Security headers tell the browser to enable extra protections. The high-value set for a PrestaShop store: X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN (anti-clickjacking), Strict-Transport-Security (add only once HTTPS is solid, see item 3), Referrer-Policy: strict-origin-when-cross-origin, and a Content-Security-Policy rolled out in report-only mode first so you don't break your own theme's scripts. CSP in particular is your strongest defence against a card-skimmer injecting a rogue script into checkout. Which is exactly how the attack in our anatomy of a Magecart-style attack on PrestaShop walkthrough plays out.
13. Put a WAF in front of the store
A web application firewall filters malicious traffic before it touches PrestaShop. Cloudflare's free plan blocks many common patterns and adds DDoS protection; Cloudflare Pro and ModSecurity (with the OWASP Core Rule Set) go further. A WAF is also your front line against volumetric and crawler-driven pressure. Including the faceted-search ?q= flood that can quietly turn PrestaShop's own filter URLs into a self-inflicted denial-of-service, which we dissect and defend with Cloudflare rules in surviving the ?q= flood.
Level 4, Module and API hygiene
14. Audit installed modules ruthlessly
Every module is code running inside your store, and every unused module is risk for no reward. Three rules: remove anything you're not actively using (disabled isn't enough. The PHP files are still reachable); never run nulled (pirated) modules, which routinely ship with backdoors; and keep everything updated, checking the developer's site for advisories. Outdated third-party modules are the most common breach vector on PrestaShop after unpatched core.
15. Lock down or disable the Webservice API
If you use PrestaShop's Webservice API (Advanced Parameters → Webservice), give each key the minimum resources it needs rather than full access, delete unused keys, require HTTPS, and restrict by IP where you can. If you don't use it, switch Enable PrestaShop's webservice to No. An over-permissioned API key is a full data export waiting to happen.
16. Remove default and sample data
Leftover demo products, sample categories and default CMS pages serve no purpose and hint at your install's age and structure. Clear them out once the store is real.
Level 5, Front-end abuse and bot control
17. Stop spam at the forms with reCAPTCHA
Contact forms, account registration, reviews and newsletter sign-ups are the doors bots walk through to flood your store with junk and probe for weaknesses. reCAPTCHA stops the automated noise without blocking real customers. Set up and tuned the PrestaShop way in our reCAPTCHA for PrestaShop guide.
18. Block bad bots and abusive visitors
Beyond CAPTCHA, you'll want to filter traffic that has no business on your store, scrapers, vulnerability scanners, and clients hammering endpoints. Real enforcement against hostile bots belongs at a WAF, server-level rules, or a dedicated security module, not in PrestaShop's core settings; Shop Parameters → Traffic & SEO only helps with robots.txt and crawler hints, which well-behaved bots respect but scanners ignore. Geolocation can restrict whole countries but isn't a scanner control either. The deeper toolkit is in visitor control: blocking bad bots and unwanted traffic. For dealing with specific repeat offenders by IP. The customer who keeps placing fraudulent orders, the one address that keeps probing, see customer extra info and IP bans.
19. Password-protect what isn't ready for the public
Staging content, wholesale pages, an unreleased collection. Anything that's live but shouldn't be indexed or browsed yet should sit behind a password rather than relying on an obscure URL. The approaches for PrestaShop are in password protection for PrestaShop.
Level 6, Monitoring, response and recovery
20. File integrity monitoring
The fastest way to catch a compromise is to notice the moment a file changes that shouldn't. File integrity monitoring (FIM) fingerprints your PrestaShop and module files and alerts you when one is modified unexpectedly. Which is precisely what happens the instant an attacker injects code into a controller or a payment template. This is the early-warning system that turns a silent breach into a same-day fix.
21. Watch your access logs
Review server access logs for the tells: bursts of requests from a single IP, repeated hits on the admin login, requests for files that don't exist (vulnerability probing), and unexpected POSTs. If your host offers fail2ban, point it at your PrestaShop logs so repeat offenders get banned automatically. Knowing what normal looks like is what lets you spot the abnormal.
22. Uptime and certificate monitoring
A free monitor like UptimeRobot watching for downtime, SSL expiry and sudden response-time spikes does double duty: it catches outages and it flags the resource drain of, say, a cryptomining payload or a traffic flood before your customers do.
23. Automated, tested, off-site backups
Back up files and database daily, keep copies in at least two places (server plus off-site cloud), and, this is the part everyone skips, actually test a restore each quarter. A backup you've never restored is a hope, not a plan. Encrypt off-site database backups (they contain customer data) with GPG. Retain something like 30 days of dailies and a few months of weeklies; storage is cheap and a clean restore point is what stands between you and starting over.
24. Write the incident-response plan before you need it
When a store is compromised, the worst time to figure out the next step is at 2am. Document it in advance: who to call (host, payment processor, a security specialist), how to drop into maintenance mode without losing in-flight orders, where the latest clean backup lives, how to restore it, and what to verify afterwards. If the worst has already happened, our step-by-step data breach response guide walks the whole sequence, GDPR notification duties included.
The special case: a store you can't upgrade yet
The checklist above assumes you can patch. Plenty of real stores can't, a heavily customised theme, a critical module with no compatible version, a platform migration that's six months out. That doesn't mean you're defenceless. Virtual patching, edge WAF rules and targeted hardening can shield a known vulnerability without touching the core, buying you time to upgrade properly. The full playbook for stuck-on-an-old-version stores is advanced PrestaShop hardening for stores you can't upgrade yet.
Where modules fit, and where they don't
Most of this checklist costs nothing but attention: settings you already own in the back office, hosting-panel toggles, an hour with your .htaccess. We'd rather you do those than buy anything. Where a module earns its place is in the items that are tedious or impossible to do by hand, chiefly 2FA and login hardening, and continuous file integrity monitoring that watches every file change for you instead of you eyeballing logs. Our security modules at mypresta.rocks cover those layers, configured from your back office without core edits so an upgrade doesn't undo them. So what? You're paying to automate the controls a human can't keep up with manually. Not to replace the free hygiene that does most of the work.
The honest summary
Security on PrestaShop isn't a project you finish; it's a standard you hold. The good news is that the attacks hitting your store are mostly dumb and automated, which means the basic, boring controls, patch, rename the admin, force HTTPS, strong passwords, 2FA, backups you've actually tested. Stop the overwhelming majority of them. Work down this list, link out to the deeper guides as you reach each control, and put a recurring quarterly reminder in your calendar to run it again. The stores that get breached are almost never the ones that did the boring things; they're the ones that meant to.
Spot-check: list every back-office account in one query
Item 2 asks you to prune the employee list and confirm nobody has quietly created an account you don't recognise. The back office shows you that under Advanced Parameters → Team → Employees, but a read-only SQL query is faster to scan and harder for a tampered admin UI to hide things from. Run this against your database (adjust the ps_ prefix to match yours), it only reads, it changes nothing:
-- Read-only: every back-office account, newest first.
-- Flag SuperAdmins (id_profile = 1) you don't recognise, and any
-- account whose date_add is recent but that nobody on your team created.
SELECT id_employee, email, id_profile, active, date_add, last_connection_date
FROM ps_employee
ORDER BY date_add DESC;Two rows deserve a second look: any id_profile = 1 (SuperAdmin) you didn't expect, and any account whose date_add lands inside a window you weren't onboarding staff. A rogue SuperAdmin created during a compromise is one of the first things an attacker plants to keep a way back in, and it survives a malware cleanup if you only scrub files. Disable in the back office rather than deleting if you want to preserve it as evidence first.
Frequently asked questions
I'm a small store with no developer. How much of this can I actually do myself?
Most of Level 1 and Level 2, renaming the admin folder, strong passwords, forcing HTTPS, turning on 2FA, pruning accounts, tightening permissions. Are back-office or hosting-panel tasks that need no code. The server-level items (file permissions, .htaccess, headers) are where it's reasonable to ask your host or a developer. Start with the plain-language version in our guide for store owners and work down from there.
Do I need a security module, or is the free hardening enough?
The free hardening does most of the work and you should do it first regardless. A module earns its place only on the two jobs that are tedious or impossible by hand: 2FA plus login hardening, and continuous file-integrity monitoring that watches every file change instead of you eyeballing logs. If you're paying, you're paying to automate those, not to replace the free fundamentals.
Is Cloudflare's free plan enough as a WAF?
For a typical store it blocks a lot of common probing and adds DDoS protection, so it's worth turning on. But the Free plan can't match on query strings or user-agents in rate-limiting rules, which matters if you're being actively targeted. For example throttling a faceted-search ?q= flood needs Pro. We cover exactly where Free stops short in advanced hardening for stores you can't upgrade yet.
How often should I run this checklist?
Put a recurring quarterly reminder in your calendar. Twenty minutes to confirm PrestaShop and modules are patched, 2FA is on for everyone, ex-employee accounts are gone, and a backup actually restores. Security on PrestaShop isn't a project you finish; it's a standard you hold.
My store is on a version I can't upgrade right now. Am I just exposed?
No, but you do shift from patching to virtual patching: edge WAF rules, locking the origin so attackers can't bypass it, and targeted fixes for the specific flaws your logs and advisories name. The full playbook for stuck-on-an-old-version stores is advanced PrestaShop hardening for stores you can't upgrade yet.
Keep reading
- Securing your PrestaShop store: a plain-English guide for store owners, the same ground with no jargon, for non-technical owners.
- Anatomy of a Magecart-style attack on a PrestaShop 1.7.x store, what these controls actually defend against, from the inside.
- Data breach response: what to do if your store gets hacked, the calm, step-by-step playbook for the first hours.
Comments
Leave a comment
Share a question, an installation detail, or feedback that could help another reader.