When Claude audited kindoflost.com, the security findings weren’t dramatic. There was no sign of an active breach, no malware, no obvious damage. But there were several open doors that bots probe automatically every day on every WordPress site on the internet — and all of them were unlocked. This post covers exactly what we found and what we did about it, none of which required editing a theme file or writing PHP.
Security hardening isn’t about paranoia. It’s about not being the easiest target on the block. Automated attacks don’t discriminate by site size — they scan everything. The fixes here are small, mostly free, and take less than an afternoon.
Fix 1: Move Your Login Page Off the Default URL
Every WordPress site in the world has a login page at /wp-login.php. That means every bot scanner in the world knows exactly where to try brute-forcing your password. It’s the digital equivalent of putting a sign on your front door that says “lock is here.”
The fix is a free plugin called WPS Hide Login. Install it, go to Settings → WPS Hide Login, and change the login URL to something non-obvious — not /login, not /admin, something that isn’t on any standard wordlist. Save the new URL somewhere safe because if you forget it, you’ll need to disable the plugin via FTP to get back in.
After setting this up, the original /wp-login.php URL returns a 404. Bots hammering that address get nothing. It’s not foolproof security on its own, but it eliminates an enormous amount of automated noise hitting your server every day.
Fix 2: Block xmlrpc.php
xmlrpc.php is a legacy WordPress file that allows remote publishing and mobile app connections. Most modern WordPress sites don’t need it at all — it predates the REST API. But it’s still there, and bots actively scan for it because it allows brute-force login attempts that bypass normal lockout protections.
The easiest way to block it is through Cloudflare. Go to Security → WAF → Custom Rules and create a rule: if URI Path equals /xmlrpc.php, block. This stops the request at Cloudflare’s edge before it even reaches your server.
Alternatively, if you’re comfortable with .htaccess, you can add these lines to your WordPress root .htaccess file:
# Block xmlrpc.php
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>You can verify it worked by visiting yourdomain.com/xmlrpc.php directly — you should get a 403 Forbidden or a block page, not the default WordPress XML response.
Fix 3: Delete readme.html
WordPress installs a readme.html file in the root of your site. It’s a leftover from the installation process and its only function at this point is to publicly display your exact WordPress version number to anyone who visits yourdomain.com/readme.html.
That version number is a roadmap for attackers. If your version has a known vulnerability, and most versions eventually do, this file tells them exactly what to target.
Delete it. Log into HostGator cPanel → File Manager → navigate to public_html → find readme.html → delete. Done. There is no reason to keep this file.
While you’re in File Manager, also check for license.txt — another WordPress default file that can expose version information. Delete that too if it’s there.
Fix 4: Stop the REST API From Leaking Your Admin Username
WordPress’s REST API is powerful and useful, but it has a default behavior that’s a quiet security problem: it exposes a list of your site’s users at /wp-json/wp/v2/users. That means anyone can visit that URL and see the username of every account on your site — including your admin account.
Your admin username is half the puzzle for a brute-force login attack. If bots know your username, they only need to guess your password. Hiding the login URL (Fix 1) reduces this risk, but you should also stop broadcasting the username in the first place.
There are two ways to address this:
- Best fix: Create a new admin account with a non-obvious username (not your site name, not “admin”, not your real name). Transfer all posts to the new account, then delete the old one. This means even if someone hits the REST API endpoint, they see a username that gives nothing away.
- Quick fix: Add a filter via the Code Snippets plugin to hide user data from unauthenticated REST API requests. Go to Code Snippets → Add New, paste the snippet below, set it to run everywhere, activate:
add_filter('rest_endpoints', function($endpoints) {
if (isset($endpoints['/wp/v2/users'])) {
unset($endpoints['/wp/v2/users']);
}
if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) {
unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
}
return $endpoints;
});After applying either fix, visit yourdomain.com/wp-json/wp/v2/users in your browser. You should get an empty array or a permission error instead of a list of usernames.
Fix 5: Verify Your WHOIS Privacy Is Actually On
Your domain registration information — name, email, address — is publicly searchable via WHOIS unless privacy protection is enabled. Many hosting companies offer this as a paid add-on, but some registrars (including Cloudflare Registrar) include it for free.
Check yours at lookup.icann.org — enter your domain and look at the Registrant section. If it shows your real name and address, your information is public. If it shows “Redacted for Privacy” or a proxy service address, you’re covered.
In the case of kindoflost.com, WHOIS privacy was already on — HostGator had been trying to sell it as an upgrade, but it turned out it was already included. Worth checking before paying for something you already have.
Fix 6: Audit and Clean Up Your Plugins
Every plugin on your site — even deactivated ones — is a potential attack surface if its files sit on the server. Inactive plugins don’t run, but they can still contain vulnerabilities that automated scanners find.
Go through your plugin list with a simple rule: if you’re not actively using it, delete it (not just deactivate — delete). For each plugin you keep, make sure it’s up to date. Outdated plugins are the single most common entry point for WordPress hacks.
During the kindoflost.com audit we found 27 plugins installed. That’s a lot for a site of this size. We identified the HTTP Headers plugin as actively flagged for a vulnerability — it was handling the X-Frame-Options security header but had been reported as a security risk itself. We replaced its function with a Cloudflare Transform Rule (covered in Post 2) and deleted the plugin entirely.
Where This Leaves You
Before this work, I would have graded kindoflost.com’s security at a D+. After these fixes — login URL hidden, xmlrpc blocked, readme.html deleted, REST API user endpoint removed, plugins cleaned up, security header moved to Cloudflare — it’s solidly in B territory.
The remaining gap to an A is mainly the admin username situation. The account named “kindoflost” is still the active admin, which means the username is guessable even without the REST API broadcasting it. Creating a new admin account with a non-obvious name and retiring the old one is the one meaningful security item still on the list.
The broader point is that none of this required a developer, a security plugin suite, or paid tools. Just knowing where to look and what to change.
Security Hardening Checklist
- Install WPS Hide Login and move /wp-login.php to a custom URL
- Block xmlrpc.php via Cloudflare WAF or .htaccess
- Delete readme.html (and license.txt) from your root folder via cPanel
- Remove or restrict the REST API user endpoint
- Verify WHOIS privacy is enabled at lookup.icann.org
- Audit plugins — delete anything inactive or flagged
- Replace any vulnerable security plugins with Cloudflare Transform Rules
- (Bonus) Create a new admin account with a non-obvious username
→ Continue to Post 4: Speeding Up a WordPress and WooCommerce Site
← Back to Post 2: How to Set Up Cloudflare Correctly for a WordPress Site
Things that I use, like, and am affiliated with:
Mint Mobile offers great cell phone service for $15 flat, get $15 off using the link. Get discounted phones with service activation and no contract.
I never spend money before I check Mr Rebates or Rakuten to get cashbacks, rebates, discounts, coupons or cheaper gift cards.