How to penetration-test a WordPress site

Get written permission before sending test traffic. Record the exact domains, subdomains, IP addresses, accounts and test window. State whether you may test plugins, APIs, file uploads, authentication and the hosting layer.

Do not start with password guessing, exploit payloads or destructive tests on a live shop. Agree on rate limits, emergency contacts and what counts as proof. The OWASP Web Security Testing Guide provides a useful structure for planning web application tests.

Take a backup and confirm that you can restore it before testing. Prefer a staging copy with production data removed or anonymised. Record the WordPress version, PHP version, web server, active theme, plugins, integrations and user roles.

Keep logs during the test and watch CPU, memory, error rates and failed logins. WordPress recommends a recovery plan, working backups and a clean comparison copy because scans and configuration changes can expose or alter files.

Begin with passive checks: inspect headers, robots.txt, public readme files, redirects, TLS, login pages, REST routes and the XML-RPC endpoint. Then use WPScan against the authorised target to identify the core version, plugins, themes, users and common backup or export files.

For example, run wpscan --url https://example.com --enumerate vp,vt,u --plugins-detection mixed --api-token YOUR_TOKEN. Mixed plugin detection finds more than passive detection but sends more requests, so lower the request rate or use passive mode on a fragile site. WPScan itself is a black-box scanner, not a complete penetration test.

Use separate test accounts for administrator, editor, author, contributor and subscriber roles. Check rate limiting, multi-factor authentication, session expiry, password-reset flows, logout, application passwords and whether a lower-privileged user can read or change another user’s content.

For each action, replay the request with the account that should not be allowed to perform it. Check both the normal dashboard request and direct requests to the underlying endpoint. Do not rely on a nonce as proof of authorisation: WordPress documents that nonces help with CSRF protection but do not replace capability checks.

Review every active and inactive plugin and theme against its current security advisories, then inspect high-risk features such as file uploads, shortcode handling, imports, redirects, search, forms, AJAX actions and custom REST routes. Test inputs for unexpected HTML, script, SQL-like characters, path traversal and unsafe file types without trying to damage data.

Check whether the REST API exposes data or permits actions without the required login and capability. Test /wp-json/ and relevant routes with both unauthenticated and role-based requests. Check /xmlrpc.php separately because XML-RPC is a distinct API and may be needed by services such as Jetpack. Do not disable either interface blindly; confirm what the site uses first.

Look for exposed configuration backups, database exports, debug logs, directory listings, forgotten staging sites, old plugins, writable PHP files and secrets in source code. Check that wp-config.php is not downloadable, file editing is disabled where appropriate, unused plugins and themes are removed, and file ownership and permissions match the hosting setup.

Separate confirmed vulnerabilities from information-only findings and false positives. For every issue, record the affected URL or component, evidence, impact, reproduction conditions, severity, fix, owner and retest result. WordPress specifically recommends limiting file write access and can disable dashboard file editing with DISALLOW_FILE_EDIT.

The manual route is fine for a small site when you understand HTTP, WordPress roles, plugin code and safe test methods. It is slower, easy to repeat inconsistently and will not automatically correlate WordPress-specific findings across a large installation.

For the fast route, use pentest-plugin when you need deeper penetration-testing checks than a routine vulnerability scan. Review every result manually, confirm it against the site’s configuration, and still produce the same evidence and remediation report rather than treating the plugin output as a complete professional penetration test.