This article is part of the WordPress Forensics series — practical guides for WordPress security, recovery, and migration.

Introduction

Most WordPress security problems are preventable. The issue is that site owners do not know what to check until after a breach. This guide walks you through a comprehensive security audit — the same checklist we use before taking on any WordPress client.

The Pre-Audit Inventory

Before diving in, document your current state:

  • WordPress version
  • PHP version
  • Active theme and version
  • List of all plugins (active and inactive)
  • All user accounts and their roles
  • Hosting provider and plan type
  • Last known backup date and location

1. Core WordPress Security

WordPress Version

  • Check: Dashboard → Updates
  • Risk: Outdated core is the #1 attack vector
  • Action: Update to latest stable version (test on staging first)

File Permissions

  • Directories: 755
  • Files: 644
  • wp-config.php: 600 or 640
  • .htaccess: 644

wp-config.php Hardening

  • Unique authentication keys (use WordPress salt generator)
  • Database table prefix changed from default wp_
  • Debug mode disabled in production
  • File editing disabled: define('DISALLOW_FILE_EDIT', true);

2. User Account Audit

Admin Account Review

  • No account named "admin" (rename if exists)
  • Minimum number of administrator accounts
  • All admin accounts have strong, unique passwords
  • Two-factor authentication enabled for all admins

User Role Audit

  • Remove unused accounts
  • Verify each user has minimum necessary permissions
  • Check for suspicious accounts (unknown emails, recent creation)
  • Review user activity logs if available

3. Plugin Security

Plugin Inventory

  • Delete all inactive plugins (not just deactivate)
  • Check each plugin's last update date
  • Verify plugins are from WordPress.org or trusted sources
  • Remove plugins not updated in 12+ months

Plugin Vulnerability Check

  • Cross-reference with WPScan Vulnerability Database
  • Check plugin reviews for security complaints
  • Verify plugin developer reputation

High-Risk Plugin Categories

  • Form builders (SQL injection risk)
  • File upload plugins (RCE risk)
  • Page builders (XSS risk)
  • SEO plugins with file access
  • Backup plugins with external storage

4. Theme Security

Theme Audit

  • Delete all inactive themes except one default (Twenty Twenty-Four)
  • Verify theme source (WordPress.org, ThemeForest, or custom)
  • Check for nulled/pirated themes (malware vector)
  • Review theme file modification dates

Child Theme Check

  • Using child theme for customizations (not modifying parent)
  • Child theme functions.php reviewed for suspicious code

5. Database Security

Database Credentials

  • Strong database password (not same as WordPress admin)
  • Database user has minimum required permissions
  • Remote database access disabled if not needed

Database Table Review

  • Check for unknown tables (possible backdoor)
  • Review wp_options for suspicious entries
  • Check wp_users for unauthorized accounts
  • Search for base64 encoded strings in post content

6. Server and Hosting

PHP Configuration

  • PHP version 8.1+ (7.x is end-of-life)
  • display_errors = Off in production
  • expose_php = Off
  • allow_url_fopen = Off (if not needed)

.htaccess Security Rules

  • Block access to sensitive files (wp-config.php, .htaccess)
  • Disable directory browsing
  • Block PHP execution in uploads directory
  • Limit login attempts via .htaccess or plugin

7. SSL and HTTPS

  • Valid SSL certificate installed
  • All pages force HTTPS (no mixed content)
  • WordPress and Site URL set to HTTPS
  • HSTS header configured

8. Backup Verification

  • Automated backups running on schedule
  • Backups stored offsite (not just on same server)
  • Both files AND database included
  • Test restore performed in last 30 days
  • Backup retention policy defined

Post-Audit Actions

  1. Prioritize findings by risk (critical, high, medium, low)
  2. Create remediation plan with timeline
  3. Implement changes on staging first
  4. Document all changes made
  5. Schedule next audit (quarterly recommended)

Conclusion

A security audit is not a one-time event — it is a recurring practice. The WordPress ecosystem moves fast, and new vulnerabilities emerge constantly. Build this checklist into your maintenance routine, and you will catch problems before attackers do.