A WooCommerce store is a more attractive target than a standard WordPress site. It processes payments, stores customer data, handles order records, and often has user accounts with saved addresses and purchase history. A compromised WooCommerce store is not just a reputational problem – it can trigger payment processor sanctions, PCI compliance violations, and legal liability for customer data exposure.
Most WooCommerce attacks are not sophisticated. They exploit predictable weaknesses: weak admin passwords, outdated plugins with known vulnerabilities, misconfigured file permissions, and login pages left open to brute force. Addressing these systematically eliminates the majority of risk without requiring advanced security expertise.
The attack surface of a WooCommerce store
Understanding what attackers target helps you prioritize what to protect.
The admin login page. wp-admin and wp-login.php are the highest-value targets. An attacker with admin access can install backdoors, exfiltrate customer data, inject malicious code into checkout pages to skim payment details, or redirect payments to their own accounts.
The checkout page. Payment skimming attacks inject JavaScript into checkout pages that silently captures card details as customers type them. These attacks happen at the server level – a compromised plugin or theme file, a vulnerable WordPress installation, or a server with lax file permissions. The customer sees nothing unusual. Their card details are sent to both your payment processor and the attacker.
Customer accounts. WooCommerce creates user accounts for customers. Credential stuffing attacks – automated scripts trying leaked email/password combinations from data breaches – target these accounts to access saved addresses, order history, and stored payment methods.
Plugin vulnerabilities. WooCommerce stores typically run a significant number of plugins – payment gateways, shipping calculators, product builders, review systems, marketing tools. Each plugin is a potential attack vector. Vulnerabilities are disclosed constantly – over 250 WordPress plugin vulnerabilities are reported every week on average. An unpatched plugin can provide a complete server compromise without any interaction from the store owner.
xmlrpc.php. WordPress’s XML-RPC endpoint supports multi-call operations that allow hundreds of login attempts in a single HTTP request, bypassing standard rate limiting. Most WooCommerce stores have no legitimate use for xmlrpc.php.
Login protection
Strong, unique credentials
This is obvious but still the cause of a significant number of compromises. Your WordPress admin password should be long, random, and used nowhere else. A password manager makes this trivial.
Do not use “admin” as your username. It is the first username attackers try. If your current admin username is “admin”, create a new admin account with a different username, transfer ownership of content to it, and delete the original account.
Two-factor authentication
Two-factor authentication (2FA) means that even if an attacker obtains your password, they still cannot log in without the second factor. For a WooCommerce store, 2FA on the admin account is not optional – it is the single most effective security measure you can take.
Plugins like WP 2FA, Google Authenticator, or Wordfence Login Security add 2FA to WordPress in minutes. Use a time-based one-time password (TOTP) app like Google Authenticator or Authy rather than SMS-based 2FA, which is vulnerable to SIM swapping.
Limit login attempts
Without rate limiting, an attacker can try thousands of passwords per minute against wp-login.php. A plugin like Limit Login Attempts Reloaded or the login protection built into security plugins like Wordfence blocks an IP after a configurable number of failed attempts.
On Hostney, server-level bot detection handles a significant portion of login-targeted bot traffic before it reaches WordPress at all – the scoring system identifies credential stuffing patterns across multiple signals and blocks attacking IPs across all servers in the fleet. But application-level login protection provides an additional layer that is worth having regardless of hosting. See What Happens When Bots Find Your WordPress Login Page for a detailed walkthrough of how these attacks work and how they are stopped.
Disable xmlrpc.php
Unless you use a mobile app or desktop client for remote publishing that requires XML-RPC, disable it entirely. The multicall vulnerability that allows hundreds of authentication attempts per request is reason enough.
On Hostney, this is a single toggle in your control panel. Navigate to your website’s WordPress settings, open the Security tab, and enable Disable XML-RPC. This blocks xmlrpc.php at the nginx level with a 403 response – no plugin needed, no configuration files to edit, and it cannot be bypassed from within WordPress.
On Apache-based hosting without a server-level toggle, you can add this to your .htaccess:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
Restrict wp-admin access by IP
If you manage your store from a consistent IP address (a home or office network), restricting wp-admin access to that IP eliminates the attack surface for login brute force entirely. An attacker from any other IP simply gets a 403 without reaching the login page.
This is a powerful protection but requires care – if your IP changes or you need access while traveling, you will be locked out unless you have an alternative access method (like SSH to temporarily remove the restriction).
SSL and HTTPS
SSL is not optional for a WooCommerce store. Any store transmitting payment data over HTTP is in violation of PCI DSS requirements and will lose the ability to accept card payments if discovered.
Every page of your store should be served over HTTPS, not just checkout. Customer login, account pages, and the cart all transmit sensitive data. Mixed content – HTTPS pages loading resources over HTTP – weakens the security of the entire connection.
Configure a 301 redirect from HTTP to HTTPS so all traffic is forced to the secure version regardless of how the URL is typed.
Enable HSTS (HTTP Strict Transport Security) to tell browsers they should never connect to your domain over plain HTTP, even if explicitly requested. This prevents SSL stripping attacks.
Verify your certificate is valid and the chain is complete using SiteProbe’s SSL checker. An expired or broken certificate disrupts checkout completely.
On Hostney, SSL certificates are provisioned and renewed automatically for all sites. See How to install an SSL certificate for details on the certificate types available and when you might need a custom certificate.
PCI DSS compliance basics
PCI DSS (Payment Card Industry Data Security Standard) is the set of requirements that any business accepting card payments must meet. Violating PCI DSS does not just risk fines – payment processors can suspend your ability to accept cards entirely.
Most WooCommerce stores fall under SAQ A (Self-Assessment Questionnaire A), the simplest compliance level, if they use a hosted payment solution where card data never touches their server. With payment gateways like Stripe, PayPal, Square, or Braintree using their hosted payment fields or redirects, cardholder data is entered and processed entirely on the payment provider’s infrastructure. Your server never sees the raw card number.
SAQ A requirements are straightforward:
- All payment pages must be served over HTTPS
- You must have a process for ensuring your payment gateway integration remains current
- You must not store card data on your server (which hosted payment fields prevent by design)
- You must have a vulnerability management process – which means keeping WordPress, WooCommerce, and all plugins updated
If you use a payment integration where card data is submitted directly to your server (some older or custom integrations do this), you fall under more complex compliance requirements (SAQ D) and need to involve a Qualified Security Assessor. For new stores, always choose payment gateways that use hosted fields or redirects.
Storing customer data
WooCommerce stores order history, shipping addresses, and customer names. While this is not payment card data (and not subject to PCI DSS directly), it is personal data subject to GDPR in Europe, CCPA in California, and various other privacy regulations depending on where your customers are located.
Minimize what you store. WooCommerce allows you to configure data retention periods. Under WooCommerce > Settings > Advanced > WooCommerce.com > Data retention, you can set how long inactive customer data and completed order data are retained. Deleting data you no longer need reduces your exposure in the event of a breach.
File permissions
Incorrect file permissions are a common vector for attackers who have obtained limited server access to escalate to full site compromise.
Standard WordPress file permissions:
- Directories: 755 – readable and executable by all, writable only by the owner
- Files: 644 – readable by all, writable only by the owner
- wp-config.php: 640 or 600 – readable only by the owner (and group if needed)
Permissions that are too permissive (777 on directories, 666 on files) allow any process on the server to write to your WordPress files. On a shared hosting server, this means other accounts could modify your files if they are on the same server and the hosting provider does not properly isolate accounts.
On Hostney, each account runs in its own container with its own process namespace. A misconfigured file permission in your account cannot be exploited by another account on the same server because there is no shared process space. The container isolation described in How Hostney isolates websites with containers means the blast radius of a compromise is limited to your own container.
That said, correct file permissions still matter within your own account. A compromised plugin running as your user can write to any file your user owns if permissions are too open.
Check and correct permissions via SSH:
# Fix directory permissions
find /path/to/wordpress -type d -exec chmod 755 {} \;
# Fix file permissions
find /path/to/wordpress -type f -exec chmod 644 {} \;
# Restrict wp-config.php
chmod 640 /path/to/wordpress/wp-config.php
Keeping everything updated
Outdated plugins are the most common entry point for WooCommerce compromises. The window between a vulnerability being disclosed and being exploited in the wild is shrinking – sometimes measured in hours, not days.
Update WordPress core immediately when security releases are published. Core security updates are typically small and safe to apply quickly. The risk of running a known-vulnerable WordPress version far exceeds the risk of a minor core update breaking something.
Update WooCommerce promptly. WooCommerce is a complex plugin with a large attack surface. Security issues are found and patched regularly. Running outdated WooCommerce is a significant risk.
Update all plugins regularly. Enable automatic background updates for plugins where possible. For plugins where you want manual control (typically page builders or complex integrations that might introduce breaking changes), check for updates at least weekly.
Remove inactive plugins. A deactivated plugin’s files still exist on disk and can still be targeted by vulnerability scanners and exploits. If you are not using a plugin, delete it entirely – not just deactivate it.
Remove inactive themes. Same logic. Keep only your active theme and one fallback (typically a default WordPress theme for troubleshooting). Delete the rest.
Subscribe to security notifications. Wordfence, Patchstack, and WPScan all offer free email notifications for new vulnerabilities in plugins you have installed. This eliminates the need to manually track disclosures.
Security hardening measures
Move wp-config.php above the web root
WordPress automatically looks for wp-config.php one directory above the web root. Moving it there means it is not accessible via HTTP even if your web server is misconfigured:
mv /var/www/html/wp-config.php /var/www/wp-config.php
This provides a safety net against server misconfigurations that might accidentally serve PHP files as plaintext.
Disable file editing in the admin dashboard
WordPress’s built-in theme and plugin editor lets admin users edit PHP files directly through the browser. If an attacker gains admin access, this editor makes it trivial to inject malicious code.
On Hostney, enable the Disable file editor toggle in the WordPress Security tab. This deploys a must-use plugin that sets the
DISALLOW_FILE_EDIT
constant automatically. Because it is a mu-plugin, it cannot be removed or overridden from the WordPress admin.
On other hosts, add this to wp-config.php manually:
define( 'DISALLOW_FILE_EDIT', true );
Disable PHP execution in uploads
The uploads directory should contain media files – images, PDFs, videos. It should never execute PHP. If an attacker uploads a PHP file disguised as an image, they can execute arbitrary code if PHP execution is permitted in that directory.
On Hostney, enable Block PHP execution in uploads in the WordPress Security tab. This adds an nginx rule that returns 403 for any .php request inside the uploads directory. The attacker can upload the file (if a plugin vulnerability allows it), but the file cannot be executed. This is enforced at the server level and cannot be bypassed from within WordPress.
On Apache-based hosting, block PHP execution by adding a .htaccess file in the wp-content/uploads directory:
<Files *.php>
deny from all
</Files>
For a deeper look at how server-level PHP restrictions limit the damage when a plugin is compromised, see Why WordPress plugin vulnerabilities are out of control.
Enable security headers
HTTP security headers tell browsers how to handle your site’s content. Several are particularly relevant for WooCommerce:
Content-Security-Policy (CSP): Restricts which scripts, styles, and resources can be loaded on your pages. A properly configured CSP prevents payment skimming scripts injected by a compromised plugin from sending card data to an external domain.
X-Frame-Options: Prevents your checkout page from being embedded in an iframe on another site, which could be used for clickjacking attacks.
Strict-Transport-Security: Enforces HTTPS as described in the SSL section above.
Check your current security headers using SiteProbe’s HTTP headers checker. It shows which headers are present and flags missing ones.
The WordPress Security tab on Hostney
The security hardening measures described above – disabling xmlrpc.php, blocking PHP execution in uploads, disabling the file editor – are all available as one-click toggles in the Hostney control panel under your website’s WordPress settings, in the Security tab. But the tab includes additional protections worth enabling:
SSO-only login. Blocks access to wp-login.php entirely and requires login through the Hostney control panel instead. This eliminates the login page as an attack surface. Brute force bots, credential stuffing scripts, and password spraying tools all hit a 403 before reaching WordPress. Logged-in users can still access wp-admin normally.
Block REST API user enumeration. WordPress exposes usernames at
/wp-json/wp/v2/users
by default. Attackers use this to discover valid usernames before targeting them with brute force attacks. This toggle blocks that endpoint at the nginx level.
Block author enumeration. The
?author=N
URL parameter is another way to discover usernames. Visiting
?author=1
redirects to the admin user’s author archive, revealing the username. This toggle returns 403 for any request with an author parameter.
Hide WordPress version. Removes the WordPress version number from the HTML source, RSS feeds, and script/style query strings. This makes it harder for automated scanners to determine your exact WordPress version and target version-specific vulnerabilities.
Block sensitive files. Blocks access to readme.html, license.txt, and changelog files in the WordPress root and in plugin/theme directories. These files reveal version information that vulnerability scanners use to identify exploitable installations.
All eight security toggles are enforced at the server level – either through nginx rules or through automatically deployed must-use plugins. They cannot be bypassed by a compromised plugin or a malicious admin session, and they require no WordPress plugins to function.
Backups
A secure WooCommerce store has a backup strategy that works. Not a plugin installed – a tested, working backup that you have verified can be restored.
Key requirements for WooCommerce backups:
- Frequency: Daily at minimum for active stores. Hourly for high-volume stores during peak periods.
- Off-site storage: Backups stored only on the same server as your site are worthless if the server is compromised. Store backups in a separate location – cloud storage, a different hosting account, or your local machine.
- Database backups: Files without the database are incomplete. Both must be backed up together.
- Test restores: A backup you have never tested restoring is not a backup – it is a hope. Restore to a staging environment periodically to verify the backup is actually usable.
On Hostney, automated backups are included with all plans. The backup system stores snapshots off-server with point-in-time restore capability.
Monitoring
Knowing when something goes wrong is as important as preventing it. For WooCommerce stores, monitoring should include:
Uptime monitoring: Alerts you immediately if the site goes down, which can indicate a security incident or a broken update.
File integrity monitoring: Detects unauthorized changes to WordPress core files, theme files, and plugin files. Wordfence includes this feature. An unexpected change to a checkout template or payment plugin file is a red flag.
Failed login alerts: Notification when repeated failed login attempts occur against your admin account. Wordfence and similar plugins provide this.
Order anomaly alerts: Sudden spikes in failed payments or unusual order patterns can indicate fraud or a compromised checkout. WooCommerce does not provide this natively but fraud prevention plugins like FraudLabs Pro or payment gateway-level fraud tools can alert you.
Summary
WooCommerce security is not a single measure – it is a stack of overlapping protections. The most impactful steps in order:
- Strong, unique admin credentials with two-factor authentication enabled
- SSL on every page with a valid certificate and HTTP-to-HTTPS redirect
- Keep WordPress, WooCommerce, and all plugins updated without delay
- Use a hosted payment gateway so card data never touches your server
- Enable server-level WordPress hardening (xmlrpc blocking, PHP upload restrictions, REST API protection, file editor disabled)
- Correct file permissions across the installation
- Remove unused plugins and themes entirely
- Daily off-site backups with tested restores
The hosting environment matters too. Container isolation, server-level bot detection, ModSecurity WAF, and real-time malware scanning provide infrastructure-level protections that complement application-level hardening. On Hostney, the WordPress Security tab puts eight server-enforced hardening measures behind one-click toggles – no plugins to install, no configuration files to edit. No amount of plugin-based security fully compensates for a hosting environment that does not isolate accounts, leaves login pages unprotected against bots, or lacks file integrity monitoring at the server level.