Question 1

Why is exposing wp-login.php dangerous?

Accepted Answer

An exposed wp-login.php is dangerous because: (1) Brute force attacks — automated bots continuously try username/password combinations against wp-login.php. A publicly exposed login page is a constant target; (2) Credential stuffing — attackers use lists of known credentials from other data breaches to try to log in; (3) Amplification attacks — wp-login.php can be used in DDoS amplification without even logging in. Mitigation: add HTTP Basic Auth in front of wp-login.php, whitelist your IP address in .htaccess, change the login URL via a plugin (e.g., WPS Hide Login), or use Cloudflare Access to add SSO-like authentication in front of the login page.

Question 2

What is xmlrpc.php and should it be disabled?

Accepted Answer

xmlrpc.php is WordPress's legacy XML-RPC API, introduced before the REST API existed. It allowed remote publishing and management of WordPress via tools like Windows Live Writer, the Jetpack plugin, and older mobile apps. It should be disabled (via .htaccess) unless you actively use: Jetpack (which uses XML-RPC for some features), the WordPress mobile app (older versions), or third-party services that specifically require it. With XML-RPC enabled, attackers can test thousands of username/password combinations in a single request (via the multicall method), bypassing login throttle plugins that count individual login attempts.

Question 3

How do I restrict access to wp-login.php?

Accepted Answer

Options from most to least restrictive: (1) IP whitelist in .htaccess — Order deny,allow / Deny from all / Allow from YOUR.IP.ADDRESS — blocks everyone except your IP; (2) HTTP Basic Auth — add an .htpasswd file and require password before the WordPress login form is even shown; (3) Change login URL — plugins like WPS Hide Login or Perfmatters move wp-login.php to a custom URL (security by obscurity but reduces bot traffic); (4) Cloudflare Access / Zero Trust — adds SSO authentication in front of the URL without touching WordPress files. Combine options for defense in depth.

Question 4

What HTTP status should wp-login.php return if it's protected?

Accepted Answer

Ideal status codes for a protected login page: 401 (Unauthorized) — returned by HTTP Basic Auth, correct and informative; 403 (Forbidden) — returned by .htaccess IP whitelist, signals access is denied; 404 (Not Found) — returned when the login URL has been moved to a custom path (best for obscuring WordPress's presence). What you don't want: 200 (OK) — the login form is fully public and accessible to anyone; 301/302 redirect to login — some security plugins redirect to /login/ which may still be publicly accessible.

URL checked	Exposed if	Risk	Fix
/wp-login.php	Returns 200 (login form visible)	Brute force, credential stuffing	IP whitelist, Basic Auth, or hide login URL
/wp-admin/	Returns 200 (no redirect or auth)	Admin panel directly accessible	Ensure redirect to wp-login.php or add Basic Auth
/xmlrpc.php	Returns 200 or 405 (POST required)	Multicall brute force, DDoS amplification	Block in .htaccess unless Jetpack is active

Login Exposure Checker

What gets checked

Frequently asked questions

Related WordPress tools

Find out if your WordPress login is exposed