An online store is a higher-value target than a regular website. It processes payments, stores customer personal information, handles order history, and often has user accounts with saved addresses and billing details. A compromised store does not just lose credibility. It can trigger payment processor sanctions, PCI compliance violations, regulatory fines, and legal liability for exposed customer data. The stakes are materially different from a brochure site or a blog.
The good news is that most ecommerce attacks exploit predictable weaknesses, not zero-day vulnerabilities or advanced techniques. Weak admin passwords, outdated software, unencrypted connections, and exposed login pages account for the majority of successful breaches. Fixing these systematically is achievable for any store owner, regardless of platform.
This guide covers the security fundamentals that apply to every ecommerce platform, with specific guidance for WooCommerce and self-hosted stores.
PCI DSS: the baseline for payment security#
PCI DSS (Payment Card Industry Data Security Standard) is the security standard that applies to any business that accepts, processes, stores, or transmits credit card data. It is not optional. If you accept credit card payments, PCI DSS applies to you.
The good news for most small ecommerce stores: if you use a hosted payment gateway (Stripe, PayPal, Square, Authorize.net), the payment processor handles the most sensitive part of PCI compliance. Card numbers never touch your server. The customer enters their card details on the payment processor’s hosted form or iframe, the processor handles the transaction, and your server only receives a confirmation token. This dramatically reduces your PCI scope.
What you are still responsible for:
- Maintaining a secure network (firewall, no default passwords)
- Protecting stored cardholder data (if you store any, which you should not)
- Maintaining a vulnerability management program (keeping software updated)
- Implementing strong access control measures (unique logins, MFA, least privilege)
- Regularly monitoring and testing networks (log review, vulnerability scanning)
- Maintaining an information security policy
For most small stores using a hosted payment gateway, PCI compliance comes down to: use HTTPS everywhere, keep your software updated, use strong passwords with MFA, do not store card numbers, and complete the annual Self-Assessment Questionnaire (SAQ A or SAQ A-EP depending on your integration method).
Never store credit card numbers on your server. Not in the database, not in log files, not in email. Use a hosted payment gateway that handles card data entirely on their infrastructure. If card numbers never touch your server, the most dangerous category of PCI violations is impossible.
SSL certificates: encryption is mandatory, not optional#
Every page on your store must be served over HTTPS. Not just the checkout page. Every page. Search engines penalize HTTP sites, browsers display “Not Secure” warnings, and customers have learned to look for the padlock icon.
For an ecommerce store, HTTPS is not a security recommendation. It is a PCI DSS requirement. Any page where customer data is submitted (login, checkout, account management, contact forms) must be encrypted in transit.
Free SSL certificates from Let’s Encrypt provide the same encryption as paid certificates. For most ecommerce stores, a free DV (Domain Validation) certificate is sufficient. You do not need an EV (Extended Validation) certificate for the green bar because browsers removed the green bar years ago. All certificate types display identically in modern browsers.
What matters is:
- HTTPS on every page, not just checkout
- HTTP-to-HTTPS redirect so no page is accessible over plain HTTP
- HSTS (HTTP Strict Transport Security) header to prevent SSL stripping attacks
- Up-to-date TLS configuration (TLS 1.2 minimum, TLS 1.3 preferred)
If your SSL certificate expires or is misconfigured, customers see a “This site can’t provide a secure connection” error and cannot access your store at all. On managed hosting, certificate renewal is automatic. On a self-managed server, set up certbot auto-renewal and monitor for failures.
Protecting customer data#
Beyond payment card data, your store holds customer names, email addresses, physical addresses, phone numbers, and order history. This data has value to attackers and is subject to privacy regulations (GDPR, CCPA, state privacy laws).
Collect only what you need. If you do not need a phone number, do not ask for it. Every piece of data you collect is data you must protect and data that increases your liability in a breach.
Encrypt data at rest. Database encryption protects customer data if the database is compromised. If your hosting provider offers database encryption, enable it.
Limit who has access. Not every employee needs access to customer data. Use role-based access control to restrict who can see order details, customer information, and payment records. On WooCommerce, this means configuring WordPress user roles so that only people who need customer data can access it.
Have a data retention policy. Do not keep customer data forever. Define how long you retain order records, customer accounts, and transaction logs, then delete data that is past its retention period. Old data you no longer need is a liability, not an asset.
Hash passwords. This should be automatic. WordPress and WooCommerce hash passwords by default. If you are on a custom platform, verify that passwords are hashed with bcrypt, scrypt, or Argon2, never stored in plaintext.
Authentication and access control#
Admin accounts
Your admin account is the highest-value target on your store. An attacker with admin access can do anything: install backdoors, modify checkout pages, exfiltrate customer data, redirect payments, and deface the site.
Use multi-factor authentication. MFA on admin accounts is non-negotiable for an ecommerce store. A stolen password without the second factor is useless. For WordPress/WooCommerce stores, plugins like Wordfence, WP 2FA, or Google Authenticator add MFA. For hosted platforms like Shopify, MFA is built in.
Use unique, strong passwords. Every admin account should have a unique password generated by a password manager. No shared passwords, no passwords based on the business name, no passwords reused from other services.
Separate admin accounts from personal accounts. If you use WordPress, do not use the same account for admin tasks and writing blog posts. Create a dedicated admin account with a strong password and MFA, and use a lower-privilege account for day-to-day tasks.
Limit admin accounts. Only people who genuinely need admin access should have it. A content writer does not need admin access. A customer service representative does not need admin access. Use the minimum privilege level required for each role.
Customer accounts
Customer accounts are targeted through credential stuffing, where attackers use email/password combinations leaked from other breaches to try logging into your store. If a customer reused their LinkedIn password for your store, the attacker gets in.
Rate limit login attempts. Block or CAPTCHA accounts after a configurable number of failed login attempts. This stops automated credential stuffing. For WooCommerce, security plugins handle this. For brute force protection at the server level, fail2ban and bot detection systems block attacking IPs before they reach the application.
Offer (or require) MFA for customer accounts. Not all platforms support this, and requiring MFA adds friction to the checkout process. At minimum, offer it as an option for customers who want it.
Monitor for credential stuffing. Watch your login logs for patterns: hundreds of failed login attempts from rotating IPs, successful logins from unusual locations, or multiple accounts accessed from the same IP. These patterns indicate automated attacks.
Keeping software updated#
Outdated software is the most exploited vulnerability category in ecommerce. Plugin vulnerabilities in particular are discovered weekly, and attackers scan for unpatched installations within hours of a vulnerability disclosure.
Update the platform. WordPress core, WooCommerce core, Shopify apps, or whatever platform your store runs on. Every update includes security patches.
Update plugins and extensions. This is where most WooCommerce compromises happen. A single outdated plugin with a known vulnerability is an open door. Update promptly, especially when the changelog mentions security fixes.
Update the server. PHP version, MySQL, the web server, and the operating system all need to be current. Running end-of-life PHP means known vulnerabilities that will never be patched.
Test updates before deploying. Use a staging environment to verify that updates do not break checkout, payment processing, or other critical functionality before applying them to production. A broken checkout page during a sale is a different kind of damage than a security breach, but it is damage nonetheless.
Remove unused plugins and themes. Every plugin is an attack surface, even if it is deactivated. If you are not using it, delete it. A deactivated plugin with a vulnerability can still be exploited because the PHP files are still on the server.
Bot protection for checkout#
Bots target ecommerce stores in ways that are different from attacks on regular websites:
Card testing. Attackers use stolen card numbers and make small test transactions on your store to verify which cards are still active. They then use the confirmed cards for larger fraud elsewhere. Card testing generates chargebacks and can get your merchant account terminated.
Inventory hoarding. Bots add products to carts and hold them there, preventing real customers from purchasing limited inventory. This is common during product launches and sales events.
Scraping. Competitors scrape your product pages, pricing, and inventory data automatically.
Checkout abuse. Bots exploit discount codes, referral programs, and loyalty points by creating fake accounts and automated purchases.
Server-level bot detection that identifies automated traffic before it reaches the application is the most effective defense. Application-level CAPTCHA on checkout adds friction for real customers but is better than no protection. For WordPress stores, server-level security works alongside application-level plugins to provide layered protection.
Security headers#
HTTP security headers tell browsers how to handle your site’s content and protect against common attack types. They cost nothing to implement and provide meaningful protection.
Content-Security-Policy (CSP). Restricts which sources can load scripts, styles, images, and other resources on your pages. This is the primary defense against cross-site scripting (XSS) attacks. A script injected by an attacker will not execute if the CSP does not allow scripts from that source.
CSP for ecommerce is more complex than for a static site because you need to allow scripts from your payment processor, analytics, live chat, and other third-party services. Start with a report-only policy to identify what needs to be allowed, then enforce it.
Strict-Transport-Security (HSTS). Tells browsers to always use HTTPS, even if the user types HTTP. Prevents SSL stripping attacks where an attacker downgrades the connection to HTTP.
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options. Prevents browsers from MIME-type sniffing, which can turn an uploaded file into executable content.
X-Content-Type-Options: nosniff
X-Frame-Options. Prevents your site from being embedded in an iframe on another site, which protects against clickjacking attacks.
X-Frame-Options: SAMEORIGIN
Referrer-Policy. Controls how much referrer information is sent when users navigate away from your site. For ecommerce,
strict-origin-when-cross-origin
prevents leaking order URLs and customer paths to third-party sites.
Referrer-Policy: strict-origin-when-cross-origin
Server-level security#
Application-level security (plugins, platform settings) is important but not sufficient. Server-level protections provide a defense layer that operates independently of the application.
Web Application Firewall (WAF). A WAF like ModSecurity inspects HTTP requests and blocks those that match patterns associated with SQL injection, XSS, directory traversal, and other common attacks. The WAF operates before the request reaches your application code, stopping attacks that would succeed if they reached WordPress or WooCommerce.
Container isolation. On properly isolated hosting, each site runs in its own container with its own PHP process, file system, and resource limits. If one site on a shared server is compromised, the isolation prevents the attacker from reaching other sites. On traditional shared hosting without isolation, a compromised neighbor site can potentially access your files.
File integrity monitoring. Server-level monitoring that detects when PHP files are modified unexpectedly. Legitimate file changes happen during updates. Unexpected changes to core WordPress files, payment plugins, or checkout templates are signs of compromise.
Automatic backups. Daily automated backups stored separately from the production server. If your store is compromised, you need the ability to restore to a known-good state. Verify that your backups include both files and the database, and test the restore process before you need it.
Platform-specific guidance#
WooCommerce
WooCommerce runs on WordPress, which means it inherits both WordPress’s strengths (extensibility, community, ownership) and its weaknesses (plugin vulnerability surface, maintenance overhead, self-managed security). For a detailed WooCommerce-specific security guide covering every hardening step, see WooCommerce security: how to protect your store.
Shopify
Shopify is a hosted platform that handles infrastructure security, PCI compliance, SSL certificates, and platform updates for you. Your security responsibilities are narrower: strong admin passwords, MFA, careful app selection (Shopify apps have access to your store data), and proper staff permission configuration. The trade-off for this reduced security burden is reduced control and flexibility.
BigCommerce
Similar to Shopify in terms of hosted security. BigCommerce handles infrastructure, PCI compliance, and platform-level security. Your responsibilities are access control, app permissions, and data handling practices.
Custom or self-hosted platforms
If you run a custom ecommerce application or a self-hosted platform like Magento, PrestaShop, or OpenCart, you are responsible for everything: server security, application security, PCI compliance, SSL configuration, updates, backups, and monitoring. The security guidance in this article applies fully, and you should also conduct regular security audits and penetration testing.
Security checklist for ecommerce stores#
- HTTPS on every page with valid SSL certificate
- HTTP-to-HTTPS redirect active
- HSTS header enabled
- Hosted payment gateway (card numbers never touch your server)
- MFA on all admin accounts
- Strong, unique passwords for every account
- Admin accounts limited to people who need them
- Software updated (platform, plugins, server)
- Unused plugins and themes removed
- Login rate limiting active
- Security headers configured (CSP, X-Frame-Options, X-Content-Type-Options)
- WAF enabled
- Automatic daily backups tested
- Customer data limited to what is actually needed
- PCI SAQ completed annually
On Hostney, ecommerce stores run in isolated containers with server-level bot detection, ModSecurity WAF, automatic SSL certificates, and daily backups. The WordPress Security tab in the control panel provides one-click hardening toggles for xmlrpc blocking, PHP upload restrictions, file editor disabling, and REST API protection. These server-level protections work alongside application-level security to provide the layered defense an ecommerce store needs.