WordPress Security in Good Hands

Before defending any system, the first step is understanding it, identifying its vulnerabilities, where they originate, and how they surface in real-world environments. Earlier this year, Patchstack, one of the leading authorities in WordPress vulnerability intelligence, released its State of WordPress Security 2025 whitepaper—a deep dive into the threats, trends, and progress shaping the WordPress ecosystem. The full report is available on Patchstack.

Here are some of the most revealing figures from the study, a snapshot of WordPress security today and the progress it has made. The numbers show a story of both growing strength and ongoing risk, highlighting WordPress’s huge presence on the web and the continuous effort needed to keep it secure.

Originally launched as a simple blogging platform, WordPress has grown into the backbone of the modern web. As of November 2025, more than 37 million websites are built with WordPress, according to data from BuiltWith. Its reach spans every sector—from business and eCommerce to entertainment, news, and even government. Among its most prominent users is the official website of The White House (whitehouse.gov), which runs on WordPress.

In the right hands, WordPress proves it can perform at scale, handling millions of visits while maintaining high standards of security, reliability, and speed. Below is a list of some popular websites powered by WordPress, with traffic data sourced from Similarweb (September 2025):

Once you have a reliable hosting, next you should barricade the doors—that is, close unnecessary ports and only allow what’s required. For a typical WordPress site, there are three main ports:

• Port 22: Used for Secure Shell (SSH) connections.
• Port 80: Unencrypted HTTP web traffic.
• Port 443: Secure, encrypted HTTPS web traffic.

You generally only need ports 22 and 443 open. Port 80 is unnecessary and should always be closed. You can configure these ports in your server settings.

Next thing, if you have a co-worker or delegate tasks to another admin, you’ll create an account for them to access the server. Always assign the least privileges necessary for their tasks, nothing more. For example, in an AWS cloud server, you can specify granular permissions (managing instance, database, storage, etc.) for each account instead of giving full administrative access. This keeps the environment secure while allowing collaborators to work effectively.

A widely accepted principle in backup strategy is the 3-2-1 rule:

• Keep 3 copies of your data: one primary and two backups.
• Store 2 copies on different media: for example, one on your server and another on an external hard drive or cloud storage.
• Keep 1 copy offsite: this ensures you can recover even if your main server is compromised or physically damaged.

This approach minimizes risk and ensures you can restore your site quickly in almost any scenario. For example, you can set up backups like this:

✦ WordPress backups: Use UpdraftPlus plugin to regularly back up your entire WordPress site, including the database, and store copies on S3 or another cloud service such as Google Drive.

✦ Server-level backups: Use your hosting provider’s snapshot or backup tool to secure the entire server.

✦ Optional local backup: Download a copy of the UpdraftPlus backup to your local computer or NAS for added safety.

This way, you’ll have multiple copies of your data: one in production, one on S3 or Google Drive, one on the server, and optionally one on your local computer or NAS. These backups are stored on different types of media—object storage (S3/Google Drive), block storage (server snapshot), and file storage (NAS), and at least two copies are offsite. Whenever you need to restore your site, your backups are ready, and if one copy is damaged, the others remain intact.

WordPress-level backups are convenient for quickly restoring content, themes, and plugin settings. Plugins like UpdraftPlus make it easy to schedule WordPress backups and store them in the cloud, such as Dropbox, Google Drive, or S3.

For a more complete solution, consider server-side backups. These can snapshot the entire server environment, including OS configuration, server settings, and all WordPress sites on that server. Tools like rsync, BorgBackup, or provider-built snapshots (AWS, DigitalOcean, etc.) provide this level of protection.

Combining WordPress-level backups with server-side snapshots ensures you can recover from both application-level issues and full system failures. Backups are only useful if they’re reliable, tested, and regularly updated. So remember to test them frequently and verify that restoration works.

The final best practice is to keep reminding yourself and your team about security. It requires steady attention over time. Let’s get acquainted with these habits:

• Document every action you take in your projects, including writing changelogs. Even small tweaks in your system should be recorded. You’ll thank yourself later when debugging.
• Develop a security policy for your team and ensure every member follows it.
• Periodically audit the system, review permissions, plugin usage, server settings, and security logs to make sure everything is in order.
• Stay current with the latest trends and developments in the industry.

With these high-level practices in place, you’ve built a strong foundation for WordPress security. You understand how to minimize risk, control your environment, and cultivate a culture that keeps security at the forefront.

In the next chapter, we’ll move from strategy to action, covering specific, practical techniques to harden your WordPress site, from system hardening to plugin configuration. This is where theory meets implementation, giving you the tools to apply everything we’ve discussed in real-world scenarios.

✦ PHP and WordPress versions: Attackers can look up known vulnerabilities and exploit them. The same applies to plugin and theme versions.

✦ Exact username data: Enables brute-force attacks.

✦ Exposed wp-config.php file: Reveals database credentials, configuration details, and the entire site setup.

✦ WP-Cron enabled: Attackers can trigger wp-cron.php repeatedly, causing WordPress to run scheduled tasks nonstop. This can lead to resource exhaustion, slow performance, or even a full site crash.

✦ XML-RPC enabled: Often abused for brute-force attacks.

✦ Other leaked data (from plugins, themes, logs, database dumps, installation paths, and more): Gives attackers additional clues and entry points, making it easier to plan a successful attack later.

You’ve already seen how WPScan can reveal your PHP version. With Nginx, its version can also be exposed, often appearing on pages served when a request is blocked by Nginx rules.

✦ To hide Nginx version: SSH to your server and open Nginx configuration file, using this command:

sudo nano /etc/nginx/nginx.confCode language: Bash (bash)

Inside the “http” block, look for “server_tokens off;” and make sure it isn’t commented out. If the line begins with a “#”, remove the “#” to enable it. If the line doesn’t exist, simply add it like this:

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        types_hash_max_size 2048;
        server_tokens off;

        ...
}Code language: Nginx (nginx)

Press Ctrl+X to close the editor, then press Y to save the file.

✦ To hide PHP version: Use this command to open php.ini file:

sudo nano /etc/php/8.4/fpm/php.iniCode language: Bash (bash)

Replace the “8.4” in that command with your PHP version. For example, if you’re using PHP 8.1, the command would be:

sudo nano /etc/php/8.1/fpm/php.iniCode language: Bash (bash)

Look for the “expose_php = Off” line. That line may begins with a “;” character, remove that “;” to enable the option. For example:

; Decides whether PHP may expose the fact that it is installed on the server
; (e.g. by adding its signature to the Web server header). It is no security
; threat in any way, but it makes it possible to determine whether you use PHP
; on your server or not.
; https://php.net/expose-php
expose_php = OffCode language: PHP (php)

Tip: Since php.ini is a very long file, you can quickly jump to the “expose_php” setting by pressing Ctrl+W to open the Search function, typing “expose”, and pressing Enter to go directly to its position.

To verify that your version numbers are actually hidden, visit any page that’s blocked by your Nginx rules and confirm that the Nginx version no longer appears. For the PHP version, you can check it directly from your computer’s terminal using this command:

curl -I https://your-site.comCode language: Bash (bash)

If PHP version exposure is not disabled, the output will include a header like:

x-powered-by: PHP/7.3.33Code language: Bash (bash)

When your site runs behind Cloudflare, all traffic should go through Cloudflare’s network. That’s where the security features, such as DDoS protection, rate limiting, bot filtering, and firewall rules actually work. But if someone can reach your server directly through its IP address, they can bypass Cloudflare entirely.

The fix is simple: tell Nginx to refuse all direct requests to the server’s IP address. You can do this by modifying a server block in Nginx configuration that catches any request not matching your real domain name.

Open Nginx config file of your website, using this command:

sudo nano /etc/nginx/sites-enabled/defaultCode language: Bash (bash)

Modify the “server” block that listen on port 80 like this:

## BLOCK HTTP ACCESS
server {
    listen 80 default_server;
    server_name _;

    location / {
        return 444;
    }
}Code language: Nginx (nginx)

What this does is tell Nginx to catch any HTTP request that doesn’t match another server block and immediately drop the connection without sending a response. With this in place, anyone trying to reach your server through its raw IP address gets nothing at all.

A secure WordPress installation follows a simple rule: files should be readable, directories should be accessible, and only the essentials should be writable by the server. The commands below tighten your WordPress filesystem to a safe state. They ensure the web server (usually “www-data” on Ubuntu) owns the installation while keeping permissions restrictive enough to block common attack paths.

Run these commands:

sudo chown -R www-data:www-data /var/www/server/wordpress

sudo find /var/www/server/wordpress -type f -exec chmod 644 {} \;
sudo find /var/www/server/wordpress -type d -exec chmod 755 {} \;

sudo chmod 400 /var/www/server/wordpress/wp-config.php

sudo chmod 600 /etc/php/8.4/fpm/php.ini
sudo systemctl reload php8.4-fpmCode language: Bash (bash)

Replace “/var/www/server/wordpress” with your WordPress installation path; and replace “8.4” with your PHP version, e.g. “8.1”, “7.3”.

What these commands do:

• Ownership (“chown”): Gives full control to “www-data”, the user that Nginx and PHP-FPM run under. This ensures WordPress can function normally.
• File permissions (644): All files become readable by the server and the system, but only the owner can modify them. This blocks unauthorized edits from the public and other system users.
• Directory permissions (755): Directories need “execute” permission so WordPress can traverse them. Setting them to “755” keeps them accessible but not writable by outsiders.
• Lock down wp-config.php (400): This file contains your database credentials, salts, and keys. Making it readable only by the server dramatically reduces the risk of accidental exposure.
• Secure php.ini and reload PHP-FPM: PHP’s configuration contains sensitive directives. Setting it to “600” ensures only the system can modify it. Reloading PHP-FPM applies the changes immediately.

WordPress uses the “WP_DEBUG” setting to enable debugging mode, and when it’s active, error details can appear directly on the front-end. This is risky. It makes your site look broken and can expose sensitive information that attackers may use to probe for weaknesses. To prevent this, open your wp-config.php file with the following command:

sudo nano /var/www/server/wordpress/wp-config.phpCode language: plaintext (plaintext)

Replace “/var/www/server/wordpress/” with your actual WordPress installation path.

Add the following lines to the file, placing them just above the line that says “/* That’s all, stop editing! Happy publishing. */“. For example:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

/* That's all, stop editing! Happy publishing. */Code language: PHP (php)

These lines enable WordPress’s debugging mode, log all error details to the /wp-content/debug.log file, and prevent those errors from being shown on the front-end.

WordPress includes a built-in file editor that lets administrators modify theme and plugin files directly from the dashboard (Tools → Theme File Editor/Plugin File Editor). It sounds convenient, but from a security perspective, it’s one of the most dangerous features in the entire platform. The reason is simple: if an attacker ever gains access to your WordPress admin panel, they can use this editor to inject malicious PHP code straight into your theme or plugins. Even legitimate administrators can cause trouble accidentally. One typo in the editor can break a theme or even crash the site.

Turning it off is easy. Open your wp-config.php file and add the following line above the “Happy publishing” comment:

define( 'DISALLOW_FILE_EDIT', true );

/* That's all, stop editing! Happy publishing. */Code language: PHP (php)

When this is enabled, the theme and plugin editors disappear from the WordPress dashboard entirely. You can still update themes and plugins normally, and you can still edit files through SFTP or SSH—just not inside the WordPress admin.

For many attacks, this one setting removes the attacker’s fastest path to full site compromise. It’s a small change that dramatically reduces risk without affecting your daily workflow.

Not every attack comes from sophisticated tools. A huge portion of brute-force attempts come from simple, automated bots that target “your-site.com/wp-admin/” to try thousands of username and password combinations. Changing your login URL to something unique, like “your-site.com/secret-gate/”, will blocks these automatic attempts and helps protect your server resources.

To do this easily, use the free Admin and Site Enhancements (ASE) plugin. ASE is a lightweight tool designed to improve WordPress performance and security. After installing it, open your admin dashboard and navigate go Tools → Enhancements → Log In/Out | Register. Then enable the “Change Login URL” option and enter your preferred login endpoint.

Limit login attempts to prevent brute-force attacks from unauthorized users. The ASE plugin lets you control how many failed login attempts are allowed per IP address before it triggers a lockout. You can set how many attempts are permitted before a 15-minute lockout kicks in, and how many lockouts will block an IP for 24 hours. To configure this, open the ASE dashboard, go to the Security tab, and enable “Limit Login Attempts.” You’ll also find a log of failed login attempts that ASE has detected and blocked.

ASE also includes other helpful security features you may want to enable, such as:

• Disable Author Archives: Return 404 (Not Found) error when trying to load author archives. Remove or disable links to author archives. Remove authors archives from the sitemap.
• Disable the generator “meta” tag: Which discloses the WordPress version number. Older versions(s) might contain unpatched security loophole(s).
• Disable the “generator” tag: Which discloses the WordPress version number.
• Disable version number on static resource URLs referenced in the “head” tag, which can disclose WordPress version number.
• Obfuscate Author Slugs: Obfuscate publicly exposed author page URLs that shows the user slugs / usernames, e.g. “your-site.com/author/taihoang/” into “your-site.com/author/a6r5b8ytu9gp34bv/”, and output 404 errors for the original URLs. Also obfuscates in “/wp-json/wp/v2/users/” REST API endpoint.
• Email Address Obfuscator: Obfuscate email address to prevent spam bots from harvesting them, but make it readable like a regular email address for human visitors.

✦ Set your display name: In WordPress, if you don’t set a display name, your actual username may appear publicly on your blog posts. That gives attackers half of the login credentials they need. Once they know the username, all they have to do is brute-force the password.

To avoid this, always set a proper display name in your admin dashboard. Go to Users → Profile, fill in your first name, last name, or a nickname, and then choose which one should appear publicly under “Display name publicly as.” Make sure the name you choose is different from your real login username.

✦ Prevent user enumeration: Hiding your display name isn’t enough. WordPress exposes user data through its REST API, allowing attackers to enumerate every account on your site. This method is known as user enumeration. You can test this yourself by adding this path to any WordPress URL: “/wp-json/wp/v2/users”. For example:

https://your-site.com/wp-json/wp/v2/usersCode language: plaintext (plaintext)

And just like that—boom—a full list of user accounts appears. It includes user IDs, usernames, roles, avatars, and a surprising amount of additional information.

To mitigate this issue, you can block requests to the user-enumeration endpoints directly at the Nginx level. This prevents attackers from probing “/wp-json/wp/v2/users” and other endpoints that expose user info.

Open your Nginx configuration file:

sudo nano /etc/nginx/sites-enabled/defaultCode language: JavaScript (javascript)

Inside the “server” block that listens on port 443, add rules like the following:

server {
    server_name taihoang.com;
    listen 443 ssl;
    root ...;

    # BLOCK AUTHOR QUERY STRING ENUMERATION (?author=ID)
    if ($args ~* "^author=([0-9]+)") {
        return 404;
    }

    # BLOCK DIRECT ACCESS TO AUTHOR SITEMAP
    location ~ ^/author-sitemap\.xml$ {
        return 404;
    }

    # BLOCK REST API USER ENUMERATION
    location ~ ^/wp-json/wp/v2/users {
        return 403;
    }

    ...
}Code language: Nginx (nginx)

To enable two-factor authentication, a reliable choice is the Two-Factor plugin. It’s free, developed by WordPress.org, and supports multiple authentication methods, including:

• Email codes
• Time Based One-Time Passwords (TOTP)
• FIDO Universal 2nd Factor (U2F)
• Backup Codes

This is a great plugin that should become part of WordPress core in the future.

One important note: if you also plan to change your default login URL, you should use another plugin (not ASE) for that purpose. Although ASE allows you to change the login URL, it does not support 2FA. It would be ideal if ASE handled both, but since it doesn’t, the best combination for this scenario is:

✦ Two-Factor: For 2FA.

✦ WPS Hide Login: For changing the login URL.

This setup gives you both a custom login URL and strong two-factor protection without compatibility issues.

Keeping unused plugins or themes around is unnecessary risk, especially on a production website. To keep your WordPress installation clean and secure:

• Delete plugins you no longer use, not just deactivate them.
• Remove themes you don’t need, keeping only your active theme and one default WordPress theme (such as Twenty Twenty-Five) as a fallback.
• Avoid accumulating “test” plugins or old themes you no longer rely on.
• Regularly audit your plugins list, especially after redesigns or feature changes.

Fewer plugins means fewer attack surfaces, fewer updates to worry about, and better performance overall.

If multiple people are working on your site, each person should have their own individual account, never share a single login among multiple users. Shared accounts make it impossible to track activity, complicate audits, and create serious security risks. You should also assign users only the permissions and roles they actually need to do their job.

It’s recommended to:

• Delete accounts that are no longer needed, such as old employees, developers, or test accounts.
• Regularly audit user roles to ensure each account has the minimum permissions required to do their job.

WordPress has a special folder called “mu-plugins” (located at “/wp-content/mu-plugins/”) that loads plugins automatically without showing them in the normal Plugins list. This makes the folder extremely powerful and also a place attackers love to hide malware. If a hacker gains access to your server, the “mu-plugins” directory is an ideal place to plant malicious code because:

• MU plugins run before all other plugins.
• They cannot be seen or deactivated from the WordPress admin dashboard.
• Many site owners forget or don’t even know the folder even exists.

Because of this, you should inspect the “mu-plugins” folder regularly to ensure nothing suspicious has been added.

What you should do:

• Check “/wp-content/mu-plugins/” regularly (or after any suspicious behavior).
• Delete files you don’t recognize.
• Store only essential and trusted mu-plugins there.

If your site suddenly behaves strangely and no plugin seems responsible, the “mu-plugins” folder is one of the first places you should investigate.

Beyond the core WordPress hardening steps, you can strengthen your site even further by adding extra security rules directly in your Nginx config. These rules help block malicious requests, protect sensitive files, reduce attack surface, and stop automated scanners from probing your site. Below is a breakdown of the rules and what each one does.

Open Nginx config file of your website by using this command:

sudo nano /etc/nginx/sites-enabled/defaultCode language: Bash (bash)

And add the following lines into the “server” block that listen on port 443:

# BLOCK XML-RPC
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}Code language: Nginx (nginx)

# BLOCK ACCESS TO SENSITIVE FILES
location ~* /(wp-config\.php|readme\.html|license\.txt|wp-settings\.php) {
    deny all;
    return 403;
}Code language: Nginx (nginx)

# DENY REQUEST TO README FILES OF PLUGINS
location ~* /(readme|changelog|license)\.(txt|md)$ {
    deny all;
    return 403;
}Code language: Nginx (nginx)

# DENY REQUEST TO DEBUG.LOG
location ~* /wp-content/debug\.log {
    deny all;
    return 404;
}Code language: Nginx (nginx)

# DENY REQUEST TO CONFIG FILES
location ~* \.(ini|log|conf|env)$ {
    deny all;
}

# DENY REQUEST TO HIDDEN FILES
location ~ /\. {
    deny all;
}Code language: Nginx (nginx)

# DENY REQUEST TO WP-CRON.PHP
location = /wp-cron.php {
    allow 127.0.0.1;
    deny all;
    return 403;
}Code language: Nginx (nginx)

# BLOCK WPSCAN AND OTHER SCANNERS
if ($http_user_agent ~* "wpscan|nikto|fimap|sqlmap|acunetix|nmap") {
    return 403;
}Code language: Nginx (nginx)

# PREVENT PHP EXECUTION IN UPLOADS
location ~* /wp-content/uploads/.*\.php$ {
    deny all;
    return 403;
}Code language: Nginx (nginx)

Even if your Nginx security rules are solid, Cloudflare can stop many attacks much earlier, including bots, scanners, spam, brute-force attempts, and common WordPress-specific exploits. To help you set up effective protection without breaking your site, I found this article provides an excellent curated list of ready-to-use Cloudflare rules: Cloudflare WAF Rules v3. These rules cover many important security cases, such as:

• Blocking access to sensitive WordPress paths.
• Filtering bad bots and automated scanners.
• Hardening login & admin URL protection.
• Whitelisting Server IP.
• And much more.

The guide explains each rule clearly, why it matters, and how to add it safely in your Cloudflare dashboard. If you’re new to Cloudflare or want a complete security baseline that doesn’t conflict with plugins or themes, this is one of the best resources you can follow.

You might wonder why you should set up additional rules in Cloudflare when you already have them in Nginx. The answer is: layered security. If one layer is compromised, misconfigured, or temporarily unavailable, the other layer is still there to protect you. Cloudflare acts as your frontline defense, every request must pass through it before reaching your server. This is where you should place most of your filters and restrictions so malicious traffic gets stopped early and never consumes your server’s resources.

If Cloudflare ever experiences issues or if traffic somehow bypasses it, Nginx becomes your second gate, enforcing the same (or most of) protections at the server level. Together, Cloudflare and Nginx form a double shield, ensuring your website remains protected even if one layer fails.