WordPress security is a practice, not a feature.

Security breaches don’t happen because of one forgotten rule. They happen because security practices aren’t layered, monitored, or maintained. This guide covers the foundational practices every WordPress site should implement — starting at the perimeter and working inward.

DNS & Cloudflare

Your first line of defense happens before traffic reaches your server. DNS routing through Cloudflare protects your site from attacks at the network edge.

What DNS routing does

DNS (Domain Name System) tells the internet where to find your site. When you route your DNS through Cloudflare instead of your hosting provider, all traffic passes through Cloudflare’s network first. Attacks, bots, and malicious requests are filtered before they ever reach your server.

What Cloudflare provides

• ✓ WAF (Web Application Firewall) — Rules that block known attack patterns
• ✓ DDoS Mitigation — Stops large-scale attacks designed to crash your site
• ✓ Bot Management — Distinguishes real visitors from automated threats
• ✓ Rate Limiting — Stops attackers from making thousands of requests per second
• ✓ DNS Security — Protects your domain from DNS hijacking

Critical: Who controls your DNS

Never let a WordPress plugin or third-party vendor control your DNS. DNS is the master key to your site. If a vendor’s service fails or you need to leave, you lose your domain routing. Cloudflare is an exception — it’s a DNS and security provider built for enterprise use, with 99.99% uptime guarantees and no vendor lock-in.

wp-config.php & File Permissions

Your hosting server has basic security rules that prevent attackers from reading, modifying, or uploading files to your site.

wp-config.php: Your site’s master configuration

wp-config.php contains your database credentials, security keys, and database prefix. It’s the file that must never be accessible to the public. Server hardening rules restrict who can read it and where it can be placed on your server.

File permissions: Who can do what

Every file and folder on your server has permissions that control who can read, write, or execute it. Correct permissions mean an attacker who gains access to your server can’t easily modify files or install backdoors. Incorrect permissions mean an attacker can.

What hardening rules prevent

• ✓ Prevents editing WordPress core files from wp-admin
• ✓ Prevents automatic plugin or theme installation (requires API keys)
• ✓ Blocks directory browsing (prevents seeing file lists)
• ✓ Forces SSL/TLS on the admin panel
• ✓ Restricts file read/write permissions to authorized users

Why this matters

Server-level hardening stops attackers from taking control even if they find a vulnerability in WordPress or a plugin. It’s the safety net beneath the site.

Login Security, Headers & Attack Surface

WordPress itself has security configurations that reduce the ways attackers can find and exploit vulnerabilities.

Login security: Your first chokepoint

Most WordPress attacks start by trying to guess admin passwords. Login security rules make brute-force attacks impractical and expose real admin usernames.

• ✓ Limit login attempts — Stop attackers from making thousands of password guesses
• ✓ Two-factor authentication (2FA) — Even if password is guessed, attacker can’t log in
• ✓ Hide or change wp-login.php URL — Makes WordPress installation less obvious
• ✓ Block user enumeration — Prevents attackers from discovering admin usernames
• ✓ Disable XML-RPC — Closes a known brute-force attack vector

Security headers: Tell browsers how to protect you

Security headers are instructions your site sends to visitors’ browsers. They tell browsers not to trust malicious scripts, not to open your site in an embedded frame on another site, and how to handle sensitive data.

Attack surface reduction: Remove what you don’t need

WordPress broadcasts a lot of information about itself — your WordPress version, installed plugins, REST API availability. Attackers use this information to find vulnerabilities. Reducing attack surface means hiding or disabling features you don’t actually use.

• ✓ Hide WordPress version numbers from public view
• ✓ Disable XML-RPC (unless you need it for mobile apps)
• ✓ Restrict REST API to authenticated users (unless your site needs public API access)
• ✓ Disable pingbacks and trackbacks (old features attackers exploit)
• ✓ Remove readme.html and license files from being served

Plugin & Theme Lifecycle

Most WordPress vulnerabilities come from plugins and themes, not from WordPress itself. Security means managing these components throughout their lifecycle.

Before you install anything

• ✓ Check when the plugin was last updated (abandoned = security risk)
• ✓ Check the developer’s update history (do they respond to security issues?)
• ✓ Search for known vulnerabilities in that plugin or theme
• ✓ Ask: Do I actually need this plugin, or is it a nice-to-have?

After you install

• ✓ Keep an inventory of what you’ve installed and why
• ✓ Remove plugins you no longer use
• ✓ Remove abandoned plugins (no updates in 12+ months)
• ✓ Test updates on a staging site before deploying to production
• ✓ Never allow automatic updates to production without testing first

Security plugins: What to watch for

Some security plugins are worth using. Others create more problems than they solve — alert fatigue, performance issues, vendor lock-in. If you use a security plugin, it should complement Cloudflare and server hardening, not replace them.

CVE: Common Vulnerabilities & Exposures

A CVE is a cataloged security flaw in software. When a vulnerability is discovered in a WordPress plugin you use, a CVE is issued. You need a process for finding out about it and fixing it.

What you need to know

• ✓ Every CVE has a unique ID (e.g., CVE-2024-1234)
• ✓ Every CVE has a severity score (1-10, higher = worse)
• ✓ Critical vulnerabilities (9-10) demand immediate action
• ✓ High vulnerabilities (7-8) need patching within 48 hours
• ✓ Medium and low vulnerabilities can be addressed in the normal update cycle

Types of vulnerabilities

• ✓ SQL injection — Attacker can read or delete your database
• ✓ Cross-site scripting (XSS) — Attacker injects malicious code into your pages
• ✓ Remote code execution (RCE) — Attacker can run code on your server (worst kind)
• ✓ Privilege escalation — Attacker with low access gains admin access
• ✓ Authentication bypass — Attacker logs in without a password

Your CVE process

1. 1. Monitor — Subscribe to CVE feeds for plugins you use
2. 2. Triage — Assess severity and relevance to your site
3. 3. Remediate — Patch immediately or disable the plugin
4. 4. Document — Keep a record of what was fixed and when

Updates, Monitoring & Incident Response

Security isn’t a one-time project. It’s an ongoing practice of updates, monitoring, and response.

WordPress core updates

WordPress releases security updates regularly. You should apply them on a schedule — weekly or bi-weekly is typical for most sites. Always test on staging first, then deploy to production during a maintenance window.

Plugin & theme updates

Same principle — test on staging before production. Never auto-update plugins or themes to production without validation. An update that breaks your site is worse than a slightly outdated plugin.

Monitoring & alerting

• ✓ Uptime monitoring — Know when your site is down
• ✓ Error monitoring — Know when things are broken
• ✓ Security alerts — Know when threats are detected
• ✓ Log review — Check for suspicious activity regularly

Incident response: When something goes wrong

Despite best efforts, incidents happen. Having a plan means you respond faster: disable compromised plugins, restore from backups, notify users, and investigate what went wrong.

This is the WHAT. Not the HOW.

This guide covers what every WordPress site should implement. The HOW — actually implementing these practices correctly and at scale — is where expertise matters.

If you’re ready to harden your WordPress site and don’t have the bandwidth or expertise to do it right, that’s where wpCRISIS comes in.