Hardening WordPress Security with AdminEase

Most "secure your WordPress" guides hand you a list of toggles and stop there. The problem is that several of these toggles will quietly break things you actually use. Gutenberg stops loading, your mobile workflow stops working, plugin auto-updates fail silently, and you will not know which toggle caused it because you flipped six of them at once.

This walkthrough goes the opposite direction. We do them in order, one at a time, with the specific failure mode for each one called out before you enable it. AdminEase groups its settings into tabs. Most of what we will touch lives under WP Admin › AdminEase › Security › Hardening, a few under Security › Access Control, and the password rules under Users › Authentication. Each section below names the exact path.

1. Force strong passwords

The single highest-leverage change in this list. WordPress's built-in password meter suggests strong passwords but does not enforce them. A user with admin rights can still set their password to password123, and on a site with multiple editors at least one will eventually do exactly that.

AdminEase enforces a real policy server-side, applied at three moments: new user registration, password reset, and profile update. The policy can require any combination of: minimum length (default 8, max 64), at least one uppercase letter, at least one lowercase letter, at least one digit, at least one special character. Each rule maps directly to a regex check, so weak passwords are rejected with a specific error message rather than silently downgraded.

2. Disable file editing from the dashboard

WordPress ships with a built-in code editor at Appearance › Theme File Editor and Plugins › Plugin File Editor. Anyone with admin rights can use it to rewrite functions.php live on a production site. An attacker who phishes a single admin password gets the same capability, which is how a remarkable number of WordPress compromises escalate from "leaked credentials" to "fully backdoored server" in under sixty seconds.

AdminEase disables both editors by writing define('DISALLOW_FILE_EDIT', true); into wp-config.php. It is the standard fix, recommended in WordPress's own hardening documentation, and there is essentially no downside on a properly managed site.

3. Disallow all file modifications (production sites only)

The stricter sibling of the previous toggle. DISALLOW_FILE_MODS blocks all file writes from the admin: no plugin installs, no plugin updates, no theme installs, no theme updates, no core updates. The site becomes read-only from WordPress's perspective.

This is exactly what you want on a production site whose deploys are managed by Git, CI/CD, or a managed-host workflow like WP Engine's Git integration. It is exactly what you do not want on a small site whose owner expects to update Yoast from the dashboard on a Tuesday afternoon.

4. Hide the WordPress version

By default, WordPress publishes its version number in two visible places that AdminEase addresses: a <generator> element in every RSS feed, and the ?ver=6.5.2 query string appended to enqueued stylesheets and scripts. An attacker scanning the web for sites running a specific vulnerable version finds you in milliseconds.

AdminEase empties the RSS generator output and strips the ?ver= parameter from script and style URLs only when the value matches the current WordPress version. Other version strings (plugin-specific cache busters, theme versions) are left alone, so this does not break asset caching elsewhere.

5. Hide the PHP version

Apache and many shared-hosting setups expose your PHP version in the X-Powered-By response header on every request. The information is useless to legitimate visitors and a free gift to vulnerability scanners. AdminEase writes an Apache rule to unset the header for every response.

The rule AdminEase adds to .htaccess (between # ADMINEASE_HIDE_PHP_VERSION BEGIN and END markers):

<IfModule mod_headers.c>
    Header unset X-Powered-By
    Header always unset X-Powered-By
</IfModule>

6. Disable XML-RPC

XML-RPC is the legacy remote-API endpoint at /xmlrpc.php. It exists so that desktop blogging clients, older mobile apps, and the Jetpack plugin can talk to your site. It is also the single most-abused endpoint in WordPress for brute-force credential attacks: a single XML-RPC request can test multiple passwords at once, which bypasses login-rate-limiting plugins that only watch wp-login.php.

If you do not use Jetpack or a remote publishing client, turn XML-RPC off. AdminEase writes a hard deny to .htaccess. Blocked at the web server, never reaches PHP, costs the attacker zero CPU on your end.

The rule written to .htaccess is the standard hard deny:

<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

7. Disable or restrict the REST API

The REST API is the modern successor to XML-RPC and is far more widely used. Gutenberg uses it. Elementor uses it. Most modern themes use it. The contact-form plugin probably uses it. You almost never want to disable the REST API outright, but you also probably do not want anonymous visitors querying /wp-json/wp/v2/users and getting a public list of every admin username.

AdminEase's compromise: a parent toggle "Disable REST API" plus a child toggle "Enable for logged-in users." Turn on both. Now anonymous requests get a 403 and the user-enumeration endpoint is closed, but Gutenberg and the page builder still work for editors who are logged in.

8. Block access to sensitive files

This single toggle adds Apache rules denying direct access to file types attackers routinely scan for: .ht* files, any .env file, wp-config.php, generic config.php and configuration.php, composer.json, composer.lock, package.json, package-lock.json, yarn.lock, files starting with .git, README and CHANGELOG files, and anything ending in .ini, .bak, .backup, .old, .orig, .tmp, .log, .sql, or ~. The same rule set also blocks the .git, .svn, and .hg directories via mod_rewrite.

The most common real-world threat this defends against: a developer who accidentally commits wp-config.php.bak or database.sql to the document root. Without this rule, those files are world-readable. With it, they return 403.

9. Block directory browsing

If a directory in your WordPress install has no index.php or index.html, Apache's default behavior is to show its contents as a clickable file listing. wp-content/uploads/ is the most common culprit. Directory listings expose filenames, modification dates, and structure that you simply do not want public.

AdminEase adds a single Apache directive, Options -Indexes, that turns directory listings off globally. Modern hosts usually have this set already, but "usually" is not "always."

10. Block author enumeration scans

Two URLs on a default WordPress site leak admin usernames to anyone who asks. The first is your-site.com/?author=1. WordPress redirects to /author/admin-username/, revealing the username in the URL. The second is /wp-json/wp/v2/users, which returns a JSON list of all users with published posts. Attackers script both, harvest usernames, and feed them to brute-force tools.

AdminEase blocks both at the Apache layer, but only for unauthenticated requests. Logged-in admins can still use the author archives normally. The rule checks for the presence of the wordpress_logged_in cookie and the Authorization header, and rejects only requests that have neither.

11. Disable pingbacks and trackbacks

Pingbacks were a 2004-era feature designed so that two blogs could automatically link to each other when one cited the other. Today they serve one practical purpose: they let an attacker use your site as an unwitting amplifier in a DDoS attack against a third party. The pingback request is small; the response WordPress sends is large. Multiply by a botnet and your site is suddenly the attack tool.

AdminEase disables pingbacks in four places simultaneously: it removes the pingback.ping XML-RPC method, strips the X-Pingback response header, sets the default ping status on new posts to "closed," and filters out internal pingbacks (the ones WordPress would otherwise send to itself when you link from one of your posts to another).