WooCommerce security checklist: 14 things to fix this week

Why this order, and where the time goes

Each item is ranked by risk reduced per hour, not by how technical it sounds. The first four get more detail because they separate an opportunistic scan from a serious incident; the rest are shorter because the right setting is obvious. The recurring cost is covered in what WordPress maintenance costs.

Fix first: the four items that close the widest gaps

1. Patch WordPress, WooCommerce and every plugin on a schedule

Open Dashboard → Updates and WooCommerce → Status for the versions you run, and check wp-config.php for AUTOMATIC_UPDATER_DISABLED and WP_AUTO_UPDATE_CORE; if either disables updates, confirm who owns patching. Auto-update low-risk plugins, but test payment gateways and WooCommerce extensions on staging. Good looks like every security release within seven days and a named owner; WooCommerce's platform documentation covers these settings.

2. Enforce two-factor authentication and limit login attempts

List every Administrator, Shop Manager and Editor under Users → All Users. WordPress has no native two-factor setting, so use a maintained plugin such as Wordfence or your host's protection, and enforce TOTP for every elevated account. Rate-limit wp-login.php and the WooCommerce login form, and use generic errors that do not confirm a username. Good looks like no shared admin login and offline recovery codes.

3. Build a plugin inventory and remove what nobody owns

Export Plugins → Installed Plugins and add four columns: purpose, owner, source and last update. Check the WordPress.org page or vendor changelog; no update in twelve months is a review item because it no longer receives fixes. Delete deactivated plugins rather than leaving their files, and treat a nulled theme as compromised. Good looks like a one-page inventory with an owner for every line.

4. Restore a backup, not just create one

Find where backups live: host panel, plugin, or both. Check frequency, retention and whether the copy sits with a different provider, because a copy on the same server leaves with it. Restore the latest copy to staging, place a test order and confirm products, customers and order notes survived. Good looks like daily backups, an offsite copy and a test in the last 90 days.

Next: access, files, secrets and exposure

5. Audit admin users and apply least privilege. Sort Users → All Users, keep one or two named Administrators, and remove contractors and former staff. Revoke unnamed application passwords under Users → Profile and REST keys under WooCommerce → Settings → Advanced → REST API. Good looks like least privilege and a quarterly review.

6. Close XML-RPC and REST API exposure. Request /xmlrpc.php; a live response means the endpoint is open, so block it at the host, WAF or plugin unless Jetpack needs it. Open /wp-json/wp/v2/users, restrict user routes, and leave the WooCommerce Store API alone because checkout needs it. Good looks like XML-RPC blocked and no user list.

7. Fix file permissions and block PHP in uploads. Check directories at 755 and files at 644, with wp-config.php at 600 or 640, and ask the host before changing ownership. Deny PHP in wp-content/uploads with an Apache rule or nginx block. Good looks like images served normally, no PHP in uploads and no directory listing. The WordPress hardening guide has the detail.

8. Review wp-config secrets and the database prefix. Check the salts, $table_prefix, DISALLOW_FILE_EDIT and FORCE_SSL_ADMIN in wp-config.php, and rotate salts after a staff change. Give the database user rights to the store database only, and change the prefix only with a migration plan: it is noise, not a boundary. Good looks like unique keys and a config file the web cannot read.

9. Force HTTPS and add the security headers that matter. Set both WordPress URLs under Settings → General to https and FORCE_SSL_ADMIN to true, then check checkout for mixed content. Add HSTS once every subdomain is HTTPS, plus nosniff, a referrer policy and CSP frame-ancestors (or X-Frame-Options), starting CSP in report-only; the OWASP headers project and MDN reference list values. Good looks like HTTPS everywhere.

Store and infrastructure: the last five

10. Put a WAF and CDN in front, then hide the origin. Confirm the WAF is blocking, not just installed, and rate-limit wp-login.php, xmlrpc.php and checkout. If a CDN fronts the store, let the origin firewall accept traffic only from it, or an attacker can bypass the WAF. Good looks like a hidden origin and a working test checkout.

11. Harden checkout and verify payment webhooks. Check each gateway's webhook secret and order status mapping under WooCommerce → Settings → Payments; custom integrations live under Settings → Advanced → Webhooks and must verify the HMAC signature. Do not mark orders Completed before payment, treat the order key like a password, and rate-limit or remove the order-tracking shortcode. Good looks like paid orders in Processing.

12. Close coupon abuse, account enumeration and session gaps. Under Marketing → Coupons, cap every public code with usage limits, individual use and an expiry. Check login and registration for messages that confirm an email exists, test /?author=1 and /wp-json/wp/v2/users for username leaks, and review guest checkout and account creation under Accounts & Privacy. Keep shared cashier sessions short; good looks like capped coupons and generic errors.

13. Turn on logging and set a retention period. WooCommerce → Status → Logs holds gateway and fatal errors, the host and WAF hold the rest; keep them out of the web root. Set a 90-day retention window and review weekly for failed logins, POSTs to xmlrpc.php, new admins and file changes. Good looks like one searchable place and someone who reads it.

14. Separate staging from production and repeat your deploys. Clone to staging, password-protect it, set noindex and never give it production payment keys. Test updates there and place a test order through every gateway, then deploy repeatably with a rollback point and a change log. Good looks like no live edits and a reversible deploy.

How do you run this on a live store without breaking checkout?

Pick the quietest 90 minutes of your week. Clone to staging, run updates and header changes there, and place a test order through every payment method. If a change must go live, take a backup and host snapshot, put the store in maintenance mode for admins only, and pause new orders at the gateway. After each change, check add-to-cart, checkout, payment, the confirmation email and the order in WooCommerce → Orders, then purge the CDN. If checkout fails, restore the snapshot first.

What this list does not do

It is not a penetration test. Nothing here breaks authentication, chains a plugin flaw or manipulates checkout logic; a clean checklist is not evidence the store cannot be abused.

It is not a compliance certification. PCI DSS, SOC 2 and ISO 27001 need scoping, evidence and an independent auditor; this page does not satisfy them.

It is not a guarantee. Patching, two-factor and tested backups reduce known risk but do not stop a zero-day or stolen credentials. If the store may already be infected, start with what to do when a website is hacked.

If you want this done for you rather than by you

Audits start at $490 and take 3 business days: a PDF, a plain-English summary and a ranked fix list. Basic is $129 a month with 1 hour and a 2-business-day response. Care at $249 adds a monthly malware and vulnerability scan, hardening, login protection and two hours of edits. Store Care at $449 adds checkout monitoring, daily backups and a quarterly review. We are not a 24/7 SOC; support runs 09:00–18:00 GMT+8 on weekdays. See what an audit covers and compare care plans.