Most WooCommerce security problems aren’t exotic. They’re the same handful of issues, repeated across store after store. This is the checklist I work through before I look at anything else - the things that are almost always worth checking, regardless of what the client thinks the problem is.
1. Plugin Inventory
Before touching anything else, I export the full plugin list and look for redundancy. It’s very common to find three plugins doing variations of the same thing - particularly for product attributes, forms, and SEO. Each plugin is an additional codebase with its own vulnerability surface and its own database access. Redundant plugins don’t cancel each other out; they stack risk.
I flag everything that’s deactivated but still installed. Deactivated plugins still exist on disk. Their files are still readable, their vulnerabilities are still exploitable in some configurations.
Reference: WPScan Vulnerability Database for checking installed plugins against known CVEs.
2. Plugin Update Status
Outdated plugins account for a significant share of WordPress compromises. I cross-reference installed versions against current releases and against WPScan’s database.
A plugin that hasn’t been updated in 12+ months with no stated reason is a flag. A plugin abandoned by its developer is a bigger one.
3. User Roles and Capabilities
I pull all users with Administrator role and ask: do all of these people need admin access? The answer is almost always no.
Custom roles created by plugins are worth checking too. Some plugins silently create roles with broader capabilities than needed. The members plugin or a quick get_editable_roles() call in a test environment shows everything.
4. Admin Account Hygiene
I check for the username admin. It’s a default that many installers never change, and it’s the first username every brute-force tool tries. If it exists and is active, it needs to change.
I also look at dormant admin accounts - former employees, old agency contacts, test accounts. These are often forgotten and never removed.
5. File Permissions
Standard permissions for a WordPress install: 755 for directories, 644 for files, 600 for wp-config.php. Anything more permissive than this is worth noting, particularly on wp-config.php, wp-content/uploads/, and any directory that contains sensitive configuration.
World-writable directories (777) are a critical finding.
6. Debug Mode and Error Display
WP_DEBUG enabled on a production site exposes stack traces, file paths, and database query details in the browser. WP_DEBUG_DISPLAY controls whether those errors show in the page output - both need to be false in production.
I check wp-config.php directly and also browse the site as an unauthenticated user while watching for any PHP notices or warnings leaking into the HTML.
7. Database Prefix
The default WordPress database prefix is wp_. Automated SQL injection tools target this prefix specifically. Changing it doesn’t prevent SQL injection, but it removes a layer of automation. I note it if it’s still the default, particularly on older installs.
8. XML-RPC
xmlrpc.php is a legacy remote procedure call endpoint that enables brute-force amplification attacks - a single request can attempt hundreds of username/password combinations. Unless the store actively uses XML-RPC (Jetpack, some mobile apps), it should be disabled.
I check whether it’s responding at /xmlrpc.php and whether any plugin is configured to use it.
9. Login Page Exposure and Brute Force Protection
The default login URL (/wp-login.php, /wp-admin/) is public. I check whether any rate limiting or lockout mechanism is in place, and whether login attempts are being logged anywhere.
Two-factor authentication for admin accounts is noted as absent if it’s not configured.
10. SSL and Mixed Content
I verify the SSL certificate is valid and not approaching expiry. I also check for mixed content - HTTP resources loaded on HTTPS pages - using browser developer tools and a quick crawl. Mixed content warnings can mask more serious issues and erode customer trust on checkout pages specifically.
11. Third-Party API Keys and Secrets
Payment gateway keys, shipping API credentials, and email service tokens all end up in wp-config.php or in plugin settings stored in the database. I check whether any of these are hardcoded in theme files or version-controlled (occasionally clients push their entire WordPress install to a public GitHub repo).
I also check whether test-mode keys are active on a live store. It happens.
12. AI and Chatbot Plugin Configuration
This one is newer but increasingly relevant. Stores are adding AI chatbot plugins - usually wrappers around the ChatGPT API - without thinking through the implications. I check whether the bot has access to real-time inventory and pricing, whether its responses are logged, whether there’s a disclaimer visible to users, and whether the system prompt has any guardrails around pricing and policy claims.
A chatbot that confidently states the wrong return policy or a price that doesn’t match the actual product listing is both a customer service problem and a potential legal one.
These twelve items don’t cover everything. But they cover what’s most likely to matter first. If you’re running a WooCommerce store and want to know where you stand on any of these, get in touch.