Server Hardening Checklist for Ecommerce Stores on a Linux VPS (2026)

An online store on a Linux VPS carries two jobs at once: it has to stay fast during a sale, and it has to protect customer accounts, order data and the checkout page. This server hardening checklist for ecommerce stores on Linux VPS hosting walks through the controls we review most often, from SSH and firewall rules to backups and payment page integrity. It is written for store owners, technical leads and agencies who want a clear list to work through.

Nothing here guarantees that a server cannot be breached, and it does not make a store compliant with any standard on its own. Hardening reduces the attack surface and makes problems easier to detect. If you would rather have a specialist do the work, our server hardening service covers each item below and is quoted in itemised form.

Why ecommerce servers need their own checklist

A brochure site that is defaced is embarrassing. A store that is compromised can leak customer details, redirect shoppers to a fake checkout or quietly skim card data. Ecommerce servers also tend to be busy, run several moving parts and be touched by many people.

• Admin panels are attractive targets: store back ends such as WooCommerce, Magento or PrestaShop are scanned by bots all day.
• Plugins and extensions add code you did not write: each one is another route in if it is outdated.
• Several people hold access: developers, agencies, marketers and support staff often share credentials.
• Downtime has a direct cost: hardening that breaks checkout is not acceptable, so changes need testing.
• Customer data is involved: orders, addresses and email lists must not sit in a world-readable location.

The server hardening checklist for a Linux VPS store

Work through these in order. The early items are quick wins; the later ones need a staging copy and a maintenance window.

1. Lock down SSH

• Disable password login and use key-based authentication only.
• Disable direct root login and use a named administrative account with sudo.
• Move SSH behind a VPN or an allow-list of known addresses where practical.
• Remove keys belonging to former staff and agencies.
• Keep a record of which key belongs to which person.

2. Configure the firewall with default deny

• Block all inbound traffic by default, then allow only web ports and SSH.
• Never expose database, cache or search ports such as MySQL, Redis or Elasticsearch to the public internet.
• Restrict outbound traffic where possible so a compromised process cannot call anywhere it likes.
• Review rules after every infrastructure change so stale exceptions do not accumulate.

3. Add brute-force protection

• Install fail2ban or an equivalent and enable jails for SSH, the web server and the store login.
• Rate-limit requests to login, password reset and checkout endpoints at the web server.
• Alert on repeated bans from the same range rather than just banning silently.

4. Patch the operating system and the stack

• Enable automatic security updates for the operating system, or schedule them weekly.
• Update the web server, PHP or runtime, database engine and the store platform itself.
• Audit plugins and themes. Remove anything unused instead of just deactivating it.
• Retire end-of-life PHP and operating system versions, because they no longer receive fixes.

Our team often finds that the operating system is fine while an abandoned plugin is the weak spot, so this step covers the application layer as well. A server hardening review normally lists both.

5. Harden the web server and PHP

• Hide version banners and disable directory listing.
• Force HTTPS everywhere, add HSTS once you are confident, and keep TLS settings modern.
• Disable risky PHP functions you do not need, and turn off display of errors in production.
• Block PHP execution inside upload and cache directories.
• Add security headers such as Content-Security-Policy, X-Content-Type-Options and Referrer-Policy.
• Run each site under its own system user and PHP pool so one compromised store cannot reach another.

6. Tighten file permissions

• Application code should be owned by a deploy user and not writable by the web server user.
• Only upload, cache and session directories need to be writable by the web process.
• Keep configuration files containing database passwords and API keys outside the web root, or readable only by the owner.
• Search for world-writable files and unexpected executable files after each deployment.

7. Remove database exposure

• Bind the database to localhost or a private network address.
• Create a dedicated database user for the store with only the rights it needs.
• Do not reuse the root database password anywhere in the application.
• Remove test databases and anonymous accounts left by default installs.
• Keep database admin tools off public URLs, or protect them behind a VPN and extra authentication.

8. Back up and test the restore

• Take regular database and file backups and store copies off the server.
• Keep at least one backup copy that the server itself cannot overwrite or delete.
• Encrypt backups, because they contain customer data.
• Practise a restore on a spare server. An untested backup is only a hope.

9. Centralise logging and alerts

• Keep web server, authentication and database logs, and send them to a separate location.
• Rotate logs so disks do not fill up during a traffic spike.
• Set alerts for new admin users, failed login bursts, unexpected file changes and unusual outbound connections.
• Agree who receives alerts and who responds out of hours.

10. Protect payment page integrity

Skimming attacks often work by adding a small script to the checkout page, not by attacking the server directly. This is why checkout needs special attention.

• Prefer a hosted payment page or embedded fields from your payment provider, so card details never touch your server.
• Keep an inventory of every script loaded on checkout and remove anything that is not essential.
• Use a Content-Security-Policy that limits which domains can run scripts on payment pages.
• Monitor checkout templates and JavaScript files for unexpected changes, and review them after every plugin update.
• Restrict who can edit theme files and tag manager containers.

Checklist summary table

Use this table to decide what to do first. Effort and risk are described in relative terms, because they depend on the size and age of your setup.

What changes the effort and cost

We do not publish prices in articles, because every store is different. These are the factors that move the quote up or down, whoever does the work.

• How many stores, domains and environments run on the VPS.
• Whether the stack is current or contains end-of-life components that need upgrading first.
• The number of plugins, custom modules and third-party scripts that need review.
• Whether a staging copy exists for safe testing.
• How much logging, alerting and out-of-hours response you want.
• Whether you need documentation for your own records or for an external reviewer.

Ask any provider for an itemised quote that separates the one-off hardening work from any ongoing monitoring, so you can compare like with like.

Mistakes we see on ecommerce servers

• Hardening live without a backup: a change to PHP or permissions can break checkout, so take a snapshot first.
• Leaving staging sites public: copies of the store with real customer data are often left open and unpatched.
• Shared admin accounts: nobody can tell who changed a theme file or created a user.
• Forgotten cron jobs and old scripts: migration leftovers sometimes run with excessive rights.
• Relying on a security plugin alone: plugins help, but they cannot fix an exposed database port or weak SSH.
• Treating hardening as a one-off task: new plugins, new staff and new versions reopen gaps.

How to run this checklist safely

Start with a full backup and, if you can, a staging copy of the server. Apply the low-effort items first, namely SSH, firewall and database binding, and confirm that checkout, payment callbacks, email sending and scheduled jobs still work after each change. Keep a written change log so you can reverse anything quickly. Schedule heavier changes, such as PHP upgrades or permission changes, outside your busiest trading periods. After the work, repeat the checks every few months and after any major plugin or platform update. If your team lacks the time, our Linux VPS hardening team can plan the work in stages around your sales calendar.

Why Companies Choose CloudHouse for Server Hardening

Clients come to CloudHouse because we plan delivery in stages, stay available for support after the work is finished and provide transparent, itemised quotes so each task has a visible scope. We test changes before they reach a live store, so checkout keeps working while the server becomes harder to attack.

Conclusion

A hardened ecommerce VPS comes from many small controls working together: locked-down SSH, a default-deny firewall, current software, careful permissions, a private database, tested backups, useful logs and a protected checkout page. No checklist removes all risk, but working through one makes your store a harder and less rewarding target. To have the list applied and documented for your own server, visit our server hardening service page and request an itemised quote.