DEV Community

Cover image for WordPress security: the 10-minute monthly checklist that catches real problems
devautomation
devautomation

Posted on

WordPress security: the 10-minute monthly checklist that catches real problems

Most WordPress security advice is useless.

"Use a strong password." "Keep plugins updated." "Install a security plugin."

These are fine, but they don't tell you what to actually check each month on client sites. Here's what I check -- based on the actual vulnerabilities and incidents I've seen managing sites for paying clients.


Why 10 minutes and not an hour

A 10-minute monthly check that actually happens is infinitely better than a comprehensive quarterly audit that gets skipped.

The goal isn't perfect security -- it's catching the 80% of problems that show up most often before they become incidents.


The monthly checklist

1. Verify WordPress core and plugins are current (2 min)

wp --allow-root core check-update
wp --allow-root plugin list --update=available --format=table
Enter fullscreen mode Exit fullscreen mode

Plugins with known CVEs get exploited within days of disclosure. Being current matters more than any security plugin.

What to watch for: Plugins not receiving updates for 6+ months. These become unpatched vulnerabilities. Deactivate and replace them.


2. Check for default admin username (30 sec)

wp --allow-root user get admin --field=login 2>/dev/null && echo "WARNING: user admin exists"
Enter fullscreen mode Exit fullscreen mode

Still the most common brute-force target. If a client's site has a user named "admin" with editor or admin role, rename it.

wp --allow-root user update admin --user_login=something_else
Enter fullscreen mode Exit fullscreen mode

3. Verify wp-config.php permissions (30 sec)

stat -c "%a" /path/to/wp-config.php
Enter fullscreen mode Exit fullscreen mode

Should be 600 or 640. If it's 644 or 777, fix it:

chmod 600 /path/to/wp-config.php
Enter fullscreen mode Exit fullscreen mode

644 means any process on the shared server can read your database credentials.


4. Check for exposed debug.log (30 sec)

[ -f /path/to/wp-content/debug.log ] && echo "WARNING: debug.log exists" || echo "clean"
Enter fullscreen mode Exit fullscreen mode

Debug logs often contain: database credentials, API keys, internal paths, email addresses, and error messages that reveal vulnerability details. If it exists, read it before deleting it -- then delete it.

Also check that WP_DEBUG_LOG is disabled in wp-config.php on production sites.


5. Audit admin users (2 min)

wp --allow-root user list --role=administrator --fields=ID,user_login,user_email,user_registered
Enter fullscreen mode Exit fullscreen mode

Compare against who should have admin access. Former employees and contractors frequently retain admin accounts. Anyone not recognized: disable immediately.

wp --allow-root user delete USER_ID --reassign=1
Enter fullscreen mode Exit fullscreen mode

6. Check for world-writable PHP files (1 min)

find /path/to/wordpress -name "*.php" -perm /o+w 2>/dev/null
Enter fullscreen mode Exit fullscreen mode

Any output is a problem. World-writable PHP files can be modified by other users on shared hosting or by malware. Fix:

find /path/to/wordpress -name "*.php" -perm /o+w -exec chmod o-w {} \;
Enter fullscreen mode Exit fullscreen mode

7. Review recent logins for anomalies (1 min)

Install the WP Last Login plugin (free) or use Wordfence logs. Look for:

  • Logins from unexpected countries
  • Multiple failed login attempts followed by success
  • Logins at unusual hours for that client

If something looks wrong: force password reset on that account immediately.


8. Check SSL certificate expiry (30 sec)

echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate
Enter fullscreen mode Exit fullscreen mode

An expired SSL breaks contact forms, ecommerce checkouts, and admin logins. Set a calendar alert for 30 days before expiry. Better: automate renewal with Let's Encrypt + certbot.


9. Verify backups ran (1 min)

Check your backup plugin's last successful run date. If it's more than 2 days ago for a WooCommerce site, or more than 7 days for a static site, something is wrong.

Also check that the backup destination is off-server. Backups on the same hosting account as the site don't protect against:

  • Hosting account compromise
  • Host-side data loss
  • Account suspension

10. Run a quick malware scan (2 min)

Wordfence (free tier) does a file integrity check:

wp --allow-root wordfence scan
Enter fullscreen mode Exit fullscreen mode

Or check core file integrity manually:

wp --allow-root core verify-checksums
wp --allow-root plugin verify-checksums --all
Enter fullscreen mode Exit fullscreen mode

Modified core or plugin files that don't match the official checksums indicate tampering. Investigate before dismissing.


The red flags that need immediate action

These aren't monthly checks -- they're things to act on the moment you see them:

  • Unknown admin users -- potential backdoor account
  • Core or plugin files modified without a recent update -- likely compromise
  • Sudden traffic spike with no marketing campaign -- bot activity or exploit
  • Site redirecting visitors to another domain -- active malware
  • Contact form sending spam -- either compromised or open relay

If you see any of these: put the site in maintenance mode first, investigate second.


Automating this

Running these checks manually across 10 client sites takes about an hour per month. The WP-CLI commands above work well in a script that loops over your client list and emails you a report.

The approach: each check writes a pass/fail to a log, then the script generates an HTML summary. If anything critical is flagged, it sends an alert email immediately.

Free checklist + the automation bundle:


What security issues do you encounter most often on client WordPress sites? Brute force, compromised plugins, or something else?


More in this series: WordPress Agency Toolkit

All tools and templates: devautomation.gumroad.com

Top comments (0)