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

Running an online store means handling real money and real customer data. That makes you a target — not because you're special, but because automated bots scan every WordPress, Magento, and PrestaShop install on the internet looking for known vulnerabilities. The good news: most attacks succeed because of basic mistakes, and basic mistakes are easy to fix. This guide covers what actually matters, in the order it actually matters.

SSL: You Have It, But Is It Working Correctly?

Every store has an SSL certificate these days. Most have it misconfigured. Having the padlock in your browser doesn't mean your store is fully encrypted — it means the page itself loaded over HTTPS. Mixed content is the hidden problem: images, scripts, or stylesheets loading over plain HTTP on an HTTPS page. Browsers quietly block these, breaking functionality without obvious error messages.

Open Chrome DevTools on your homepage, go to Console, and look for "Mixed Content" warnings. Fix them by updating any hardcoded http:// URLs in your theme, modules, or database settings. In PrestaShop, check Shop Parameters → General and make sure both the shop domain and SSL domain point to your HTTPS URL.

Also verify your HTTP-to-HTTPS redirect is working at the server level, not just inside PrestaShop. If someone visits http://yourstore.com, they should get a 301 redirect to https://yourstore.com before PrestaShop even loads. Check your .htaccess — the redirect rule should be before the PrestaShop rewrite rules, not buried inside them.

Your Admin URL Is Public Knowledge

Every default PrestaShop install puts the admin panel at /admin followed by a random suffix PrestaShop generates on install. That suffix is not a security feature — it's just inconvenience. Bots enumerate common patterns. Your admin URL is not as hidden as you think.

Rename the admin directory to something that doesn't contain the word "admin". Pick something meaningless — avoid dictionary words entirely. This won't stop a determined attacker with access to your files, but it eliminates mass automated scanning instantly.

If your hosting supports IP whitelisting via .htaccess, use it. Add a Require ip directive inside your admin folder's .htaccess to allow only your office and home IP addresses. Yes, this is inconvenient when you travel. Yes, it's worth it.

Employee Accounts: One Person, One Account, No Exceptions

Shared admin accounts are one of the most common causes of security incidents — and the hardest to investigate afterward. When every employee logs in as "admin", you have no audit trail. You can't tell who deleted a product, who changed a price, or who exported the customer list at 2am.

Create individual accounts for every person who needs backend access. Use PrestaShop's permission profiles properly: a customer service rep doesn't need access to payment settings. A warehouse operator doesn't need access to employee management. The principle of least privilege isn't bureaucracy — it limits blast radius when an account gets compromised.

Audit your employee list quarterly. Remove accounts for people who no longer work for you. Former employees with active credentials are a real threat vector, and it's one you control entirely.

Module Security: The Attack Surface You're Not Watching

Modules are the most common entry point for PrestaShop store compromises. A vulnerable module — even one you're not actively using — can be exploited if it's installed and enabled. Attackers don't care that you haven't touched that payment module in two years. If it's there and vulnerable, it's a door.

Only install modules from sources you trust. The PrestaShop Addons marketplace vets submissions, but third-party sites and random GitHub repos do not. Nulled modules — paid modules distributed free illegally — almost always contain backdoors. The economics are simple: why would someone give away paid software for free? Because they've added something to it.

Remove modules you don't use. Not just disable — uninstall and delete the files. Every installed module adds code that loads on every request, increasing both attack surface and page load time. Do a module audit: if you haven't used it in six months and don't plan to, it goes.

Update your modules regularly. Most module vulnerabilities are patched quickly once discovered — but the patch only helps if you install it. Our Security Revolution module includes file integrity monitoring that flags unexpected changes to your module files, and our Total Defender module adds active protection layers including bot blocking and suspicious activity logging.

Database Backups: The Only Thing That Guarantees Recovery

Backups are not a security measure — they're a recovery measure. The distinction matters because it changes how you think about them. No backup strategy prevents an attack. Good backups mean an attack doesn't end your business.

Automate your backups. Manual backups get skipped, delayed, and forgotten. Set up a cron job that dumps your database nightly and copies it off-server. "Off-server" means somewhere that a compromise of your web server doesn't also compromise your backups — a separate cloud storage bucket, your local machine, anywhere that isn't the same machine that could get wiped.

Test your restores. A backup you've never restored is not a backup — it's a file with unknown contents. Run a test restore to a staging environment at least once a quarter. You don't want the first time you restore from backup to be during an actual incident.

Keep multiple restore points. Daily backups for the last 30 days, weekly for the last six months. Some attacks — particularly database manipulation — aren't discovered immediately. You need to be able to restore to a point before the compromise began.

Passwords and Two-Factor Authentication

PrestaShop has supported two-factor authentication natively since version 1.7.6. If you're not using it for your admin accounts, turn it on today. The setup takes five minutes. Go to your profile in the back office and enable 2FA using an authenticator app like Google Authenticator or Authy.

Require 2FA for all admin accounts, not just yours. An employee with a weak password and no 2FA is the weakest link in your security chain.

On passwords: use a password manager and generate long random passwords for every account. "Long" means 20+ characters minimum for admin accounts. Never reuse passwords across services. Your PrestaShop admin password should appear nowhere else — not your hosting panel, not your email, not your module marketplace account.

File Permissions: The Basics Still Matter

The correct file permissions for a PrestaShop install are 755 for directories and 644 for files. If you or your hosting provider ever set permissions to 777 "to fix a problem", go back and fix it properly instead. World-writable files mean any process on the server — including code injected through a vulnerability — can modify them.

Check permissions on your config/settings.inc.php file specifically. It contains your database credentials. It should be 444 or 640 — readable by the web server, not writable by anyone.

If you're on shared hosting, your risk profile is higher because you're sharing a server with other sites. A compromise of another site on your server can potentially affect yours if permissions are too open. This is one of the real arguments for VPS over shared hosting for stores handling real transaction volume.

Keep PrestaShop and PHP Updated

Old PHP versions don't just run slower — they stop receiving security patches. PHP 7.4 reached end-of-life in November 2022. If your host is still running it (and many shared hosts still are), you're running known-unpatched vulnerabilities in your server's language runtime. Check your PHP version in the PrestaShop back office under Advanced Parameters → Information.

PrestaShop releases security patches in minor versions. Running 8.1.0 when 8.1.7 is available means you're running with known security holes. Major version upgrades require more care, but minor version updates within the same branch are generally safe and should be applied promptly after a backup and staging test.

.htaccess Hardening

PrestaShop's default .htaccess is a starting point, not a finished security configuration. Add these rules to block direct access to directories that should never be publicly accessible:

• Block direct access to /config/ — contains database credentials and encryption keys
• Block direct access to /var/ — contains cache files and logs
• Block direct access to /vendor/ — contains third-party library files
• Block direct access to /src/ — contains core source files
• Block execution of PHP files inside /upload/ — a common malware upload target

For the upload directory specifically, add a .htaccess inside /upload/ that denies PHP execution. If an attacker uploads a PHP shell through a file upload vulnerability, this rule prevents them from executing it.

GDPR and Cookie Security

Cookie security isn't just about compliance — improperly configured cookies can expose session tokens and authentication data. Make sure your session cookies are set with the Secure flag (only transmitted over HTTPS) and HttpOnly flag (not accessible to JavaScript). If you need a proper GDPR cookie consent implementation that doesn't break your store's functionality, our Cookies Revolution module handles this correctly.

If You Get Hacked: What to Actually Do

First: don't panic, but act fast. Every hour of delay is more potential damage.

Isolate immediately. Take your store offline or put it in maintenance mode. If your host has a "suspend site" option, use it. You need to stop the bleeding before you diagnose the wound.

Don't delete anything yet. Your instinct will be to clean up, but you need to preserve evidence to understand what happened. Take a full backup of the compromised state before you start removing files.

Check file modification dates. Run a search for files modified in the last 30 days. Compare against your deployment history. Files that changed without a corresponding update are indicators of compromise. Pay particular attention to PHP files in /upload/, /img/, and module directories — places where file writes are expected and easier to hide.

Restore from a clean backup. Don't try to surgically remove malware from a live site — attackers are good at hiding backdoors, and you'll miss something. Restore from a backup you're confident predates the compromise.

Change every password. Database password, FTP credentials, hosting panel, PrestaShop admin accounts, email accounts associated with the domain. Assume everything was readable during the compromise period.

Find the entry point. This is important for preventing recurrence. Common entry points: a vulnerable module, compromised employee credentials, a brute-forced admin password. If you can't identify how it happened, it will happen again.

Notify appropriately. If customer data was accessed — email addresses, order history, any payment data — you likely have legal notification obligations depending on your jurisdiction. GDPR requires notification within 72 hours of becoming aware of a breach. Don't sit on this.

Security isn't a feature you add once and forget. It's maintenance, like keeping your store's content fresh or your inventory accurate. Set a quarterly reminder to audit employee accounts, check module updates, and verify your backups are actually restoring. Twenty minutes every three months is much cheaper than recovering from a breach.

Related Articles

• Payment Security in PrestaShop: PCI Compliance, 3D Secure and Fraud Prevention
• PrestaShop Security Hardening: The Complete Checklist
• Data Breach Response: What to Do If Your Store Gets Hacked