WordPress Security: A Practical Hardening Guide

WordPress powers a large share of the web, which also makes it a large target. Most compromises are not exotic. They come from weak passwords, outdated plugins, misconfigured servers, and neglected maintenance. The good news is that a disciplined baseline eliminates the overwhelming majority of real-world attacks. This guide walks through that baseline in a practical order, then shows how you can use an AI assistant responsibly to audit and reason about your configuration.

Start with account and access hygiene

The single highest-value change you can make is protecting the ways people log in. Attackers automate credential stuffing and brute-force attempts against wp-login.php constantly.

• Remove the default admin username. Never use admin. Create a new administrator account with an unpredictable username, then delete the old one and reassign its content.
• Enforce strong, unique passwords. Require a password manager for every user with elevated privileges. Reuse is the leading cause of account takeover.
• Enable two-factor authentication. Use a reputable 2FA plugin or your host’s built-in option for all administrator and editor accounts.
• Apply least privilege. Most users do not need administrator rights. Assign the lowest role that lets them do their job (Author, Editor, or a custom role).
• Limit login attempts. Rate-limit or lock out repeated failures, and consider renaming or protecting the login URL to cut down on automated noise.

Keep the software surface small and current

Every plugin and theme is code you are trusting. Vulnerabilities in third-party extensions are a common entry point, so treat your plugin list as an attack surface to be minimized.

• Update core, plugins, and themes promptly. Enable automatic updates for security releases where you can, and review major updates in staging first.
• Delete what you do not use. Deactivated plugins and unused themes still ship code that can be exploited. Remove them entirely.
• Vet before you install. Prefer actively maintained plugins with recent updates, a healthy install base, and responsive maintainers. Abandoned plugins are liabilities.
• Avoid nulled or pirated extensions. They frequently carry backdoors. There is no such thing as a free premium plugin.

Harden the server and file system

WordPress runs on a web server, and much of your defense lives below the application layer.

• Serve everything over HTTPS. Use a valid TLS certificate, redirect HTTP to HTTPS, and enable HSTS once you are confident the site works fully over TLS.
• Set correct file permissions. A common baseline is 644 for files and 755 for directories. The web server should not be able to write to files it does not need to modify.
• Protect sensitive files. Block direct access to wp-config.php, and consider moving it one level above the web root. Deny access to hidden files and backup artifacts.
• Disable file editing in the dashboard. Add define('DISALLOW_FILE_EDIT', true); to wp-config.php so a compromised admin session cannot edit theme or plugin code directly.
• Disable PHP execution in upload directories. The wp-content/uploads folder should never run PHP. Block it at the web server level.
• Rotate your security keys. Regenerate the authentication salts in wp-config.php to invalidate stolen session cookies.

Add a firewall and monitoring layer

A web application firewall (WAF) filters malicious requests before they reach WordPress. You can run one at the host or CDN level, or through a security plugin. Pair it with visibility so you notice problems early.

• Use a WAF. Cloud WAFs also give you rate limiting, bot mitigation, and protection against common injection patterns.
• Enable file integrity monitoring. Get alerted when core files change unexpectedly, which is a strong indicator of compromise.
• Centralize and review logs. Track failed logins, admin actions, and unusual traffic. Alerts are only useful if someone reads them.
• Set security headers. Add a Content Security Policy, X-Content-Type-Options, Referrer-Policy, and a sensible frame policy to reduce cross-site scripting and clickjacking risk.

Secure the database and backups

Your database holds everything that matters. Backups are what let you recover when prevention fails.

• Change the default table prefix. Moving away from wp_ raises the bar for some automated SQL injection attempts.
• Restrict database access. Use a dedicated database user with only the privileges WordPress needs, and never expose the database port to the public internet.
• Automate encrypted, off-site backups. Store copies away from the production server, and verify that restores actually work. A backup you have never tested is a hope, not a plan.

Using AI to audit your setup

An AI assistant is genuinely useful for reviewing configuration files, explaining log entries, and generating hardening rules, as long as you treat it as an advisor and not an authority. Models can be wrong, so verify any suggestion against official WordPress and server documentation before applying it.

You can build a small internal tool using an official SDK, either anthropic for Python or @anthropic-ai/sdk for TypeScript/Node. Authenticate with the ANTHROPIC_API_KEY environment variable. For a deeper reasoning task like reviewing a config for security gaps, a capable model such as claude-sonnet-4-6 works well, and on 4.6 and newer models you can enable adaptive thinking so the model allocates reasoning as needed.

import os
from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment

with open("wp-config-redacted.php") as f:
    config = f.read()

message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=2048,
    thinking={"type": "adaptive"},
    messages=[
        {
            "role": "user",
            "content": (
                "Review this WordPress config for security weaknesses. "
                "List concrete hardening steps and cite the WordPress "
                "setting each one maps to.\n\n" + config
            ),
        }
    ],
)

print(message.content)

A few rules keep this safe and effective:

• Redact secrets first. Never paste live database credentials, API keys, or salts into any prompt. Strip or replace them before sending.
• Ask for citations. Request that the model point to the specific directive or setting so you can confirm it yourself.
• Treat output as a draft. Apply changes in staging, test, and only then promote to production.

If you want to go further, the Model Context Protocol (MCP), an open standard for connecting models to external tools and data, lets you build a controlled workflow where an assistant can read (but not blindly modify) your configuration through a defined interface. Keep the model’s access read-only for auditing tasks, and require a human to approve any change.

Build a maintenance rhythm

Security is not a one-time project. Set a recurring schedule: apply updates weekly, review logs and user accounts monthly, test a backup restore quarterly, and rotate credentials and keys after any staff change or suspected incident. A short, consistent routine beats an occasional heroic cleanup every time.

Takeaway

Most WordPress breaches are preventable with fundamentals: strong authenticated access, a minimal and current plugin set, a hardened server, a firewall with monitoring, and tested backups. Layer these defenses so no single failure exposes the whole site. Use AI to accelerate audits and explain your logs, but keep secrets out of prompts and verify every recommendation. Discipline, not novelty, is what keeps a WordPress site secure.