WordPress Security Hardening: Login, XML-RPC, 2FA, Files & Recovery

WordPress security hardening is the process of reducing attack surface, limiting account abuse and making compromise harder—not flipping one setting and declaring the site secure.

The highest-value controls are usually:

• Keeping WordPress core, plugins and themes updated.
• Using strong unique passwords and multi-factor authentication.
• Removing unused administrator accounts and unused software.
• Protecting backups and recovery access.
• Limiting unnecessary application/API exposure.
• Restricting file modification from the dashboard where appropriate.
• Monitoring authentication and security events.

Last verified: September 24, 2026.

---

---

1. Start With Updates and Supported Software

Outdated software increases exposure to known vulnerabilities.

Keep current:

• WordPress core.
• Plugins.
• Themes.
• PHP.
• Web server and operating system where you manage them.

Remove plugins and themes you no longer need instead of simply deactivating them indefinitely.

WordPress supports plugin/theme auto-updates on a per-component basis. They can reduce patch delay, but they are not a substitute for backups and post-update validation. WordPress documentation specifically recommends maintaining recoverable backups before relying on automatic updates.

Also check Tools → Site Health for background-update problems. A site that cannot reach WordPress.org or whose scheduled update tasks are failing can silently miss security fixes.

---

2. Use Least Privilege for WordPress Accounts

Not every user needs Administrator access.

Give each person the lowest role that allows them to do their work.

Review:

• Old staff accounts.
• Contractor accounts.
• Unused administrator accounts.
• Shared accounts.

Prefer individual accounts so activity can be attributed to a real user.

---

3. Protect Administrator Accounts With MFA

Strong unique passwords reduce credential reuse risk, but MFA adds another control when passwords are stolen or guessed.

For interactive browser logins:

• Use a password manager.
• Use a long unique password.
• Enable MFA/2FA through a trusted solution supported by your hosting or WordPress stack.
• Protect the email account used for password recovery.

---

4. Protect the Recovery Path Before Tightening Access

Security changes can lock out legitimate administrators just as effectively as attackers if there is no recovery path.

Before changing login URLs, WAF rules, HTTP authentication, XML-RPC, REST authentication or file-modification settings, confirm:

• The WordPress administrator email is current and protected with MFA where supported.
• You can reach hosting control-panel, SSH/SFTP or file-manager recovery access.
• You have a recent backup and know how to restore it.
• You can disable a broken plugin outside wp-admin if necessary.
• At least one trusted administrator account works before the change.
• You know how to reverse the exact change you are about to make.

Keep a working administrator session open while testing login/WAF changes, and verify a second fresh login before ending the original session.

---

5. wp-login.php Is Public by Design

WordPress login commonly uses:

/wp-login.php
/wp-admin/

Attackers and bots know those locations.

Changing the login URL can reduce commodity bot noise, but it should be treated as obscurity—not a replacement for:

• MFA.
• Rate limiting.
• Strong passwords.
• WAF/security controls.
• Patch management.

---

6. Rate-Limit Login Abuse

Brute-force and credential-stuffing attacks repeatedly attempt authentication.

Controls can include:

• Application/WAF rate limits.
• Login-attempt throttling.
• CAPTCHA or challenge controls where justified.
• IP reputation controls.
• MFA.

Test carefully so legitimate administrators are not locked out during an incident.

---

7. Extra Authentication Around wp-admin Can Help—But Test AJAX

WordPress's official hardening documentation notes that adding server-side authentication around /wp-admin/ can create a second barrier.

However, overly broad protection can break WordPress functionality such as:

/wp-admin/admin-ajax.php

Apply server-level restrictions only if you understand the application's required paths.

---

8. Should You Disable XML-RPC?

Not automatically.

WordPress still documents XML-RPC as an API used by clients and remote publishing workflows.

Before restricting it, determine whether your site uses:

• Remote publishing clients.
• Mobile applications.
• Jetpack or related integrations.
• External automation using XML-RPC.

If nothing depends on XML-RPC, reducing unnecessary authenticated methods can be reasonable.

---

9. Important: xmlrpc_enabled Does Not Fully Disable XML-RPC

The WordPress xmlrpc_enabled filter is often misunderstood.

Official WordPress documentation says this filter controls XML-RPC methods requiring authentication. It does not fully disable every XML-RPC method or the endpoint itself.

Example:

add_filter( 'xmlrpc_enabled', '__return_false' );

Use this only when you understand the behavior and have tested integrations. If your policy is to block the xmlrpc.php endpoint completely, that belongs at the web-server/WAF/application routing layer and should be tested separately; the xmlrpc_enabled filter alone is not a full endpoint block.

---

10. Pingbacks Are a Separate XML-RPC Concern

Because xmlrpc_enabled does not control every XML-RPC method, pingback exposure should be assessed separately.

If your site does not need pingbacks but still needs authenticated XML-RPC publishing, WordPress exposes the xmlrpc_methods filter for more granular method-level control.

add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

Test this on staging first. Do not publish a snippet described as “disable XML-RPC completely” unless it actually blocks the endpoint or removes every method your environment exposes.

---

11. Application Passwords Are Safer Than Sharing Your Main Password

WordPress Application Passwords are designed for programmatic access.

They are:

• Tied to a specific WordPress user.
• Individually revocable.
• Designed for APIs/integrations.
• Stored hashed by WordPress.
• Shown only when created.

They cannot be used as normal interactive wp-login.php passwords.

By default, WordPress makes Application Passwords available on HTTPS sites and local development environments. The user profile can show each credential by name plus usage metadata such as last-used time and last IP, which makes stale integrations easier to identify and revoke.

Create a separate Application Password per integration instead of reusing one credential across several tools. Revoke it immediately when the integration is retired or a secret may have leaked.

---

12. Do Not Blanket-Block the REST API

The WordPress REST API is a normal part of modern WordPress and is used by core features, the block editor, authenticated integrations, plugins, headless front ends and external automation.

Do not disable /wp-json/ globally just because it is public.

A safer approach is to:

• Keep WordPress and plugins updated.
• Use capability checks for protected actions.
• Use authenticated access for operations that modify data.
• Use Application Passwords or another supported authentication method for external integrations.
• Rate-limit or block abusive traffic at the WAF/server layer when needed.
• Remove or restrict plugin-specific endpoints only when you understand their dependencies.

Public REST responses and authenticated REST actions are not the same risk. Treat the API according to endpoint behavior and permissions rather than applying a universal block.

If an endpoint exposes data you do not intend to publish, fix that endpoint's permission/data-exposure design. Hiding /wp-json/ globally is not a substitute for correct capability checks and authentication.

---

13. Review Application Passwords Regularly

Go to the user's profile and review application credentials.

Remove credentials for:

• Retired scripts.
• Old mobile apps.
• Previous integrations.
• Former team members.

Use descriptive names so each credential can be identified later.

For administrators working over SSH, current WP-CLI also supports creating, listing and revoking Application Passwords. This is useful for repeatable operations, but command output can expose newly generated credentials, so keep terminal logs and CI output private.

---

14. Use HTTPS for Authenticated API Access

WordPress's current Application Password documentation emphasizes HTTPS because credentials sent with HTTP Basic Authentication must be protected in transit.

If you need help choosing between certificate types rather than configuring WordPress, use our Best SSL Certificates guide.

---

15. Disable the Built-In Theme/Plugin File Editor Where Appropriate

If administrators do not need to edit plugin/theme files inside wp-admin, disable the editor through DISALLOW_FILE_EDIT in wp-config.php. The next section shows the exact distinction between that setting and the broader DISALLOW_FILE_MODS.

This reduces one convenient code-editing path if an administrator account is compromised.

It does not prevent an attacker who already has server/file-system access from changing files.

---

16. Understand DISALLOW_FILE_EDIT vs DISALLOW_FILE_MODS

DISALLOW_FILE_EDIT disables the built-in plugin and theme file editors:

define( 'DISALLOW_FILE_EDIT', true );

DISALLOW_FILE_MODS is much broader:

define( 'DISALLOW_FILE_MODS', true );

Official WordPress documentation says DISALLOW_FILE_MODS blocks plugin/theme installation and update functionality from the WordPress admin area and also disables the file editors.

Use it only when updates are handled through another reliable deployment process. Do not turn off dashboard updates on a site whose team has no alternative patch workflow.

---

17. File Permissions Must Match Your Hosting Model

Common Linux WordPress deployments often use conservative permissions such as:

• Directories around 755.
• Files around 644.

But ownership, web-server user, PHP execution model and hosting platform matter.

Do not recursively change permissions from a generic tutorial without understanding your server. First identify the file owner, web-server/PHP user, deployment user, group memberships and whether your host intentionally manages permissions for you.

---

18. Protect wp-config.php

wp-config.php contains sensitive configuration values.

Also keep WordPress security keys and salts unique. If you suspect stolen authentication cookies, rotating the keys/salts can invalidate existing authentication cookies and force users to authenticate again. Plan that as an incident-response action because it affects legitimate sessions too.

Protect it through:

• Correct filesystem permissions.
• Proper ownership.
• Server configuration that does not expose PHP source.
• Backups stored outside the public web root where possible.

---

19. Database Prefix Changes Are Not a Primary Security Control

Changing the default WordPress table prefix can reduce assumptions in badly written automated attacks, but it should not be treated as a major hardening layer.

Patch vulnerabilities, protect credentials, restrict privileges and back up data first.

---

20. Disable Unused Plugins and Themes by Removing Them

Inactive software can still become a maintenance burden.

Keep only:

• The active theme.
• A known fallback theme if your operations require it.
• Plugins the site genuinely uses.

Before deleting anything, confirm there is no dependency.

---

21. Backups Are a Security Control

A hardening plan is incomplete without recovery.

Back up:

• Database.
• wp-content.
• Configuration files.
• Infrastructure configuration where relevant.

Keep at least one backup copy outside the production server and test restoration periodically.

A useful restore test verifies more than whether an archive exists. Confirm the database imports, media/files are complete, credentials/secrets are handled safely, the site boots on a clean environment, scheduled jobs work, and administrators can authenticate after recovery.

---

22. WordPress Recovery Mode Helps With Fatal Errors, Not Compromise

WordPress has a built-in Recovery Mode for certain fatal PHP errors. When triggered, WordPress can email the administrator a special recovery link and temporarily pause the faulty plugin or theme for that administrator's recovery session.

This is useful after a broken update or code change, but it is not malware cleanup or incident response. Recovery Mode does not prove files are trustworthy, credentials are safe or an attacker has been removed.

Protect the administrator email account because Recovery Mode depends on it. If recovery email fails, keep an independent path such as hosting file access, SFTP or SSH so a broken plugin can be disabled outside wp-admin.

---

23. Protect the Registrar and DNS Accounts Too

A secure WordPress admin cannot protect a domain if an attacker controls the registrar or DNS provider.

Use MFA, unique passwords and least privilege on those accounts.

For DNSSEC, records and domain-level configuration, use our DNS Configuration Best Practices Guide.

---

24. Security Headers Are Supporting Controls

Depending on the application, server and third-party integrations, useful headers can include:

• Content-Security-Policy.
• Strict-Transport-Security.
• X-Content-Type-Options.
• Referrer-Policy.

Do not paste a strict Content Security Policy into production without testing scripts, analytics, embeds, checkout flows and other required resources.

---

25. Separate WordPress Controls From Server Controls

Some protections belong in WordPress; others are more reliable at the host, reverse proxy, web server or operating-system layer.

On managed hosting, many server-layer controls are the provider's responsibility. On a self-managed VPS, they are yours.

---

26. WAF and CDN Security

A reverse proxy or web application firewall can help with:

• Rate limiting.
• Known malicious requests.
• Bot challenges.
• Origin shielding.

It is another layer, not a substitute for patching the application.

---

27. Logging and Monitoring

Useful signals include:

• Repeated failed logins.
• New administrator accounts.
• Plugin/theme changes.
• Unexpected file modifications.
• Unexpected outbound requests.
• New or unexpected Application Passwords.
• Unexpected password/email/role changes on administrator accounts.
• Availability failures.

Security monitoring should focus on events you can act on rather than generating a flood of unactionable alerts.

---

28. If the Site Is Already Compromised

Do not treat normal hardening as incident response.

If compromise is suspected:

• Preserve useful evidence where possible.
• Reset compromised credentials, including hosting, database, SFTP/SSH, registrar and recovery-email credentials where relevant.
• Revoke suspicious sessions and Application Passwords.
• Rotate WordPress salts/keys when stolen authentication cookies are a concern.
• Replace compromised code with known-good copies.
• Update vulnerable components.
• Check administrator accounts.
• Check DNS and registrar access.
• Restore from a known-good backup when appropriate.

If WP-CLI is available, wp core verify-checksums can compare WordPress core files against WordPress.org checksums, and wp plugin verify-checksums --all can verify plugins distributed through WordPress.org. A checksum mismatch is evidence to investigate, not automatic proof of malware; premium/custom plugins may not have WordPress.org checksums.

For the broader cross-platform security framework, use our Website Security Checklist.

---

29. WordPress Security Hardening Checklist

• Run a supported current WordPress release.
• Update WordPress core.
• Update plugins and themes.
• Remove unused plugins/themes.
• Remove unused admin accounts.
• Use unique passwords.
• Enable MFA.
• Protect the administrator/recovery email account.
• Confirm hosting/file-level recovery access before restrictive changes.
• Rate-limit login abuse.
• Review XML-RPC dependencies.
• Review Application Passwords and their last-used metadata.
• Test security changes on staging when they can affect login, APIs, caching or integrations.
• Disable dashboard file editing if not required.
• Use DISALLOW_FILE_MODS only when another update/deployment process exists.
• Verify file ownership/permissions.
• Protect wp-config.php.
• Back up off-server.
• Test restores.
• Protect registrar/DNS accounts.
• Monitor meaningful security events.

---

30. Common WordPress Hardening Mistakes

• Renaming wp-login.php and assuming the site is secure.
• Disabling XML-RPC without checking dependencies.
• Claiming xmlrpc_enabled disables the entire endpoint.
• Sharing the primary admin password with integrations.
• Blanket-blocking the REST API without understanding which WordPress features or integrations depend on it.
• Installing multiple overlapping security plugins.
• Using world-writable permissions to fix a deployment error.
• Storing the only backup on the same server.
• Ignoring registrar and recovery-email security.
• Running unsupported PHP or abandoned plugins.
• Setting DISALLOW_FILE_MODS and accidentally removing the team's only update path.
• Assuming Recovery Mode means a compromised site is clean.
• Applying login/WAF restrictions without preserving an independent recovery path.

---

31. Final WordPress Security Decision Framework

Recovery access + current backup confirmed?
   ↓
If no → fix recovery first

Known vulnerable / outdated software?
   ↓
Patch or remove it

Account compromise risk?
   ↓
Unique password + MFA + least privilege + rate limiting

Integration needs API access?
   ↓
Use revocable application credential where supported

XML-RPC unused?
   ↓
Restrict only after dependency check

Admin should not edit code?
   ↓
Disable dashboard file editor

Recovery plan missing?
   ↓
Back up off-server + test restore

WordPress hardening works best as a layered operating practice, not a collection of one-time code snippets.

---

Frequently Asked Questions

Should I disable XML-RPC in WordPress?

Only if your site does not need the XML-RPC functionality you plan to restrict. Check mobile apps, Jetpack, remote publishing and other integrations first.

Does the xmlrpc_enabled filter completely disable XML-RPC?

No. WordPress documentation says it disables authenticated XML-RPC methods, not every method or the endpoint itself.

Should I hide wp-login.php?

You can change or obscure the login route to reduce automated noise, but it is not a replacement for MFA, rate limiting, patching and strong credentials.

What are WordPress Application Passwords?

They are revocable per-application credentials for programmatic access. They are separate from the user's main password and are not used for interactive wp-admin login.

Should I disable the WordPress file editor?

If administrators do not need to edit theme/plugin files from wp-admin, disabling the editor can remove one convenient code-modification path after account compromise.

What file permissions should WordPress use?

Permissions depend on ownership and hosting architecture. Values such as 755 for directories and 644 for files are common starting points on many Linux deployments, but they are not universal.

Do security plugins make WordPress secure?

No single plugin can replace updates, account security, least privilege, backups, infrastructure security and monitoring.

Are backups part of security?

Yes. Reliable off-server backups and tested restoration are critical recovery controls.

Should I use DISALLOW_FILE_MODS?

Only if your site has another reliable process for installing and updating plugins/themes. WordPress documentation says DISALLOW_FILE_MODS blocks those dashboard modifications and also disables the built-in file editors.

Does WordPress Recovery Mode clean malware?

No. Recovery Mode is designed to help administrators regain access after certain fatal PHP errors by temporarily pausing the faulty component for that recovery session. It is not a malware scanner or incident-response system.

Are Application Passwords available on every WordPress site?

WordPress makes them available by default on sites served over HTTPS and on local environments, unless a plugin, policy or custom filter disables them.

What should I do before a major hardening change?

Confirm a current backup, working restore/recovery access, protected administrator email, hosting/SFTP/SSH access where applicable, and an exact rollback plan. Then test the change on staging or with a second fresh login before closing the known-good session.

---

Continue Securing and Speeding Up WordPress

Security hardening pairs with performance work. Keep going with the WordPress pillar:

• WordPress Performance Optimization: Caching, PHP, Database & Core Web Vitals
• WooCommerce Speed Optimization: Cart, Checkout & Cache
• WordPress Block Themes vs Classic Themes: Site Editor, theme.json & Workflow
• 7 Lightweight WordPress Themes to Compare for Speed & Flexibility
• WordPress REST API vs WPGraphQL: Queries, Caching, Auth & Headless Trade-Offs
• Best WordPress Hosting: Cloudways, Hostinger, Bluehost & EasyWP
• Best Hosting for WooCommerce: Compare Cloudways, Hostinger, Bluehost, Kamatera & HostGator
• HTML5 & CSS3 Best Practices: Semantic & Accessible Web Design