WordPress Penetration Testing and Hardening: A Defensive, Permission-First Guide

Key takeaways

• Most WordPress compromises come through outdated plugins and themes, so patching them matters more than hiding the login page.
• Block brute force with login rate limiting, MFA and unique admin usernames, and keep wp-config.php outside public reach with strict permissions.
• If a site is already compromised, restore from a clean backup, rotate all credentials and salts, and find the entry point before going live again.

WordPress runs a large share of the web, so it is a constant target. If you train in security, you need to understand WordPress from both sides: how weaknesses appear, and how to close them. This article stays on the defender's side. It describes what the common tools look at and how to read their output, without providing a ready-to-run attack recipe.

Before you test: scope and the law

Only test a site you own or have explicit written permission to assess. In India, accessing or testing a computer system without authorisation is an offence under the Information Technology Act, 2000 (sections 43 and 66). "It was only a scan" is not a defence.

• Get written authorisation that names the exact domains, IPs and time window in scope.
• Practise on systems built for it: your own local WordPress install, a disposable VM, or a lab such as DVWA or a deliberately vulnerable WordPress image.
• Bug bounty: only test targets whose published programme puts them in scope, and stay within its rules.
• Keep records: what you tested, when, and under whose authority.

Why WordPress gets attacked

Most WordPress incidents are not clever zero-days. They come from a small set of avoidable problems:

What are the tools, and what do they look at?

Security testers and defenders use the same scanners. Knowing what they report helps you read your own logs and fix problems.

• WPScan enumerates the WordPress version, installed plugins and themes, and checks them against a vulnerability database. Defenders run it against their own site to see what an outsider can learn and whether any component has a known CVE.
• WhatWeb / Wappalyzer fingerprint the technologies a site exposes. If they reveal your exact plugin versions, that is information you can reduce.
• Nikto checks a web server for exposed files, outdated software and common misconfigurations.
• Burp Suite / OWASP ZAP are intercepting proxies used to review how an application handles input. On your own app, they help you test for issues such as injection and broken access control.

Running these against your own staging site, with permission, tells you what an attacker would see first. The official WPScan project and the OWASP Top 10 are good references for what to check and why it matters.

Reconnaissance: what a site leaks, and how to reduce it

The first thing an attacker learns is which software you run. Confirming a site is WordPress is trivial (theme paths, /wp-json/, the login page). Version and plugin disclosure is the part you can control.

• Remove the WordPress version from page source and feeds where your setup allows it.
• Do not leave readme.html, backup files or .zip archives in the web root.
• Treat user enumeration (author pages, the REST users endpoint) as information leakage and restrict it if you do not need it public.

The goal is not secrecy as a defence, it is removing easy wins. A patched, well-configured site is safe even if the attacker knows exactly what it runs.

What are login attacks and how do you stop them?

Brute forcing and credential stuffing remain the most common way WordPress sites fall. The defence is well understood, so apply all of it:

• Limit login attempts and add an increasing delay or lockout after repeated failures.
• Require two-factor authentication for every account that can log in, administrators first.
• Enforce strong, unique passwords and screen them against known breached-password lists.
• Protect or disable xmlrpc.php if you do not use it, because it has historically been abused to multiply login guesses in a single request.
• Watch the logs. A spike of failed logins from many IPs is credential stuffing in progress; a web application firewall can absorb much of it.

If you run a test against your own site, the useful output is simply "did my rate limiting and lockout trigger?". If they did not, that is the finding to fix.

Vulnerable plugins and themes

Most real WordPress compromises trace back to a plugin or theme with a known vulnerability. Treat every add-on as part of your attack surface.

• Install only what you need, from reputable sources, and remove the rest completely (deactivating is not enough).
• Keep core, plugins and themes updated, and enable automatic updates for security releases where you can.
• Subscribe to a vulnerability feed (WPScan, your host's advisories) so you hear about a flaw before attackers scan for it at scale.
• On your own site, a scanner that flags an outdated component with a CVE is giving you a patch list, not an exploit plan. Patch, then re-scan.

Protecting wp-config.php and the database

wp-config.php holds your database credentials and secret keys, so it is the file an attacker most wants to read. Keep it out of reach:

• Set restrictive file permissions (typically 640 or 600 for wp-config.php; 644 for most files and 755 for directories), owned by the correct user.
• Block web access to sensitive files at the server level, and never leave database dumps or backups in a web-accessible folder.
• Use a strong, unique database password and a non-default table prefix on new installs.
• Rotate the WordPress secret keys if you suspect exposure, which invalidates stolen session cookies.

A WordPress hardening checklist

1. Update core, plugins and themes, and remove anything unused.
2. Enforce 2FA and strong passwords for all logins.
3. Limit login attempts and put the site behind a web application firewall.
4. Disable the built-in file editor by setting DISALLOW_FILE_EDIT to true in wp-config.php, so a stolen admin session cannot edit theme code in the browser.
5. Correct file and directory permissions; protect wp-config.php and uploads.
6. Restrict or disable xmlrpc.php and tighten the REST API if you do not need them public.
7. Serve the site over HTTPS and keep TLS current.
8. Take regular off-site backups and test that you can restore them.
9. Log authentication and admin actions, and review them; alert on unexpected new admin users.
10. Give each person the least privilege their role needs, and remove stale accounts.

The official WordPress hardening guide covers the server-side settings in more detail.

What should you do if a site is already compromised?

Signs include unexpected admin accounts, modified core files, new scheduled tasks, outbound spam, or redirects to unfamiliar sites. Respond in order:

1. Take the site offline or into maintenance mode to stop ongoing damage.
2. Preserve logs before you change anything, so you can work out how entry happened.
3. Restore from a known-good backup rather than trying to clean a live, infected install.
4. Rotate all credentials and secret keys, then patch the weakness that allowed entry.
5. Only bring the site back once the root cause is fixed; removing the symptom is not enough.

Learn WordPress security properly

If you want to practise web-application testing legally in a lab, our Web Application Hacking and Security (WAHS) and Web Application Penetration Testing courses cover authorised testing, OWASP issues and reporting. For the wider foundation, see our round-up of ethical hacking tools in Kali Linux and the web application VAPT interview questions if you are heading into the field.

Related reading

• A Step-by-Step Guide to Webcam Exploitation in a Lab Setup
• Password Cracking with Hashcat: Techniques and Best Practices
• SQLmap Commands Explained: A Practical Guide to Testing SQL Injection Vulnerabilities