If you’ve ever tried to connect an external app or service to your WordPress site, maybe a mobile app, Zapier, Postman for API testing, or a headless front-end pulling content through the REST API, you might’ve run into the dreaded Application Passwords Disabled message.
“Application passwords have been disabled by Wordfence.”
And if you’re anything like most site owners, your first reaction was probably something close to: “Umm, okay? But why?”
Don’t worry, this isn’t a bug, and your site isn’t broken. Wordfence is being extra protective because Application Passwords open a real, if narrow, door into your site if they’re not managed carefully, and Wordfence’s default posture leans cautious rather than permissive. Let’s walk through what this actually means, why Wordfence specifically cares, and how to fix it properly rather than just disabling security to make the message go away.
So, What Are Application Passwords Again?
Application Passwords were introduced as a core WordPress feature in version 5.6 (December 2020) as a way for external apps to authenticate against your site’s REST API without using your actual account password. Each application password is a separate, randomly generated credential tied to a specific app name you choose, so you can revoke access to one connected tool (say, a Zapier integration you no longer use) without changing your main login password and breaking every other connection.
Practically, it’s the mechanism behind things like the official WordPress mobile app connecting to a self-hosted site, Jetpack’s REST API features, headless WordPress setups pulling content into a separate front-end (Next.js, Astro, or similar), and any Zapier or Make.com automation that reads or writes WordPress content through the REST API.
Here’s the catch: because an application password grants API-level access with the same capabilities as the user account it’s attached to, a leaked or overly broad application password is a real attack surface, particularly on a site that also allows XML-RPC or has a weak underlying admin password. That’s exactly the class of risk Wordfence is reacting to when it disables the feature by default under certain conditions.
Also Read: Top 5 WordPress SEO Plugins and Tools
Why Wordfence Disables Application Passwords
Wordfence’s job is to protect your site like a genuinely cautious security guard, and in this case, it treats Application Passwords as a feature that’s easy to misuse if the surrounding security posture isn’t solid. Specifically, Wordfence’s Login Security module (built on the older Wordfence Login Security standalone plugin, now folded into the main Wordfence Security plugin) will disable Application Passwords when:
- Your site doesn’t force HTTPS (SSL) sitewide, since application password credentials transmitted over plain HTTP are exposed to anyone intercepting the connection.
- You have Wordfence’s own two-factor authentication or brute-force protection features active in a configuration that specifically flags application passwords as a bypass risk, since a stolen application password can sometimes route around 2FA depending on how a third-party app authenticates.
- The plugin detects an unusual pattern in your authentication setup, such as a mismatch between your declared site URL and the REST API’s actual endpoint, which can indicate a misconfigured reverse proxy or a compromised install.
None of this means Wordfence is trying to block you from using your tools. It’s a default-safe posture: disable the feature until the surrounding conditions (HTTPS, in particular) are confirmed solid, then let you turn it back on deliberately.
Also Read: 10 Best WordPress Plugins for Improving Core Web Vitals
How to Re-Enable Application Passwords Safely
Good news: you can turn Application Passwords back on, and in nearly every case it just means bringing your site up to the baseline security Wordfence is checking for.
1. Make Sure Your Site Actually Forces HTTPS
Wordfence will not allow Application Passwords on plain HTTP, full stop. If your site still shows “Not Secure” in the browser address bar, install an SSL certificate. Most hosts (SiteGround, Kinsta, WP Engine, Cloudways) offer one-click free SSL through Let’s Encrypt directly in the hosting dashboard. It’s worth checking beyond just “does the padlock show” too: use a tool like Why No Padlock or your browser’s dev tools to confirm there’s no mixed content (HTTP images or scripts loading on an HTTPS page), since mixed content can cause some security plugins to treat HTTPS as only partially enforced.
Once HTTPS is genuinely active sitewide, including on the REST API endpoints themselves, Wordfence will stop blocking the feature on that basis.
2. Check Your Wordfence Login Security Settings
In your dashboard, go to:
Wordfence > Login Security > Settings
Scroll to the section labeled “Application Passwords” and confirm “Enable Application Passwords” is toggled ON. If the toggle is greyed out or unavailable, that’s your signal the HTTPS check above hasn’t passed yet, fix that first and the toggle typically becomes available.
3. Verify Your WordPress User Role
Application Passwords only work for roles with sufficient capability, by default:
- Administrators
- Editors
- Authors
- Any custom role explicitly granted REST API access
Subscribers typically can’t generate or use them under WordPress core’s default capability checks, regardless of what Wordfence allows, so if a lower-privilege user reports they can’t see the option, that’s expected core behavior rather than a Wordfence issue.
Also Read: 7 Best WordPress Image Compression Plugins Compared
4. Test Generating a New Application Password
Go to:
Users > Profile > Application Passwords
Enter a descriptive name for the app you’re connecting (not just “app1”, something you’ll actually recognize later, like “Zapier - order sync” or “Mobile App - iPhone”), and try generating a new password. If it succeeds, you’re set. If not, double back through the HTTPS and Login Security checks above.
Common Tools That Actually Rely on Application Passwords
It helps to know what you might be breaking if you leave the feature disabled rather than fixing the underlying HTTPS gap. Application Passwords power a wider range of everyday WordPress connections than most site owners realize:
- The official WordPress mobile app (iOS and Android), when connecting to a self-hosted site rather than one managed through WordPress.com, authenticates through Application Passwords by default on recent versions.
- Zapier and Make.com automations that read or write posts, users, or custom post types through WordPress’s native REST API connector.
- Uncanny Automator, when it’s triggering actions on a separate WordPress install rather than the same site.
- Headless front-ends built in Next.js, Astro, or Gatsby that pull content from WordPress as a pure content backend, a genuinely common architecture for sites wanting a decoupled front-end while keeping WordPress as the editorial workspace.
- Postman or Insomnia, when a developer is testing or debugging custom REST API endpoints during plugin or theme development.
- WP All Import’s remote/API-based import workflows, and similar bulk content tools that authenticate over the REST API rather than direct database access.
If any of these are part of your actual stack, that’s a good reason to prioritize the HTTPS fix rather than leaving Application Passwords disabled indefinitely, since each of those integrations will simply fail to authenticate until the underlying block is resolved.
Application Passwords vs XML-RPC: Not the Same Thing
Site owners sometimes conflate this message with the older, unrelated advice to “disable XML-RPC” for security. They’re different systems. XML-RPC (xmlrpc.php) is a much older WordPress remote-access protocol, still used by some legacy tools and the Jetpack/WordPress.com connection, that’s been a frequent target for brute-force and DDoS-amplification attacks specifically because it allows many authentication attempts through a single request. Application Passwords, introduced years later specifically to modernize and partially replace XML-RPC’s authentication use case, work through the REST API and support per-app, individually revocable credentials, a meaningfully safer design.
Disabling XML-RPC (which Wordfence and most security plugins can also do, as a separate setting) is generally safe if you’re not using Jetpack or a legacy tool that specifically requires it. Don’t confuse that unrelated setting with the Application Passwords toggle covered here, they solve different problems and disabling one doesn’t affect the other.
How to Revoke a Specific Application Password
If you’re cleaning up old credentials as part of getting this properly configured, or you suspect one has leaked, revoking a single application password without affecting others takes under a minute:
- Go to Users > Profile > Application Passwords (or Users > All Users > [specific user] > Application Passwords if you’re an administrator managing another account).
- Find the named entry for the specific integration in the list, this is exactly why descriptive naming at creation time matters.
- Click “Revoke” next to that entry. It takes effect immediately, that specific credential stops authenticating on the next request.
- If the integration is still needed, generate a fresh application password and update the credential inside the connected app or service, the app-side reconnection step is usually the slower part of this process, not the WordPress side.
Quick Way to Confirm the REST API Itself Is Reachable
Before assuming the issue is Application Passwords specifically, it’s worth confirming your REST API is reachable at all, since a server-level block would produce a similar-looking failure. From a terminal, a simple unauthenticated request should return JSON, not an error page or a blank response:
curl -s https://yourdomain.com/wp-json/If that returns a JSON structure describing your site’s available routes, the REST API itself is reachable and the issue is specifically in the Application Passwords authentication layer, pointing back to the Wordfence and HTTPS checks above. If it returns an error, 403, or nothing at all, the block is happening earlier, at the server or WAF level, and the fix is on that layer rather than inside WordPress.
What If You Still Can’t Enable Application Passwords?
A few things beyond Wordfence itself can still block the feature, worth checking in order:
- A second security plugin running alongside Wordfence, such as Solid Security (formerly iThemes Security), Sucuri Security, or WP Cerber, any of which can independently disable Application Passwords through their own REST API hardening settings. Running two security plugins with overlapping REST API restrictions is a common, easy-to-miss cause, check each plugin’s settings individually rather than assuming only Wordfence is involved.
- Cloudflare or another CDN/WAF enforcing HTTPS at the edge but not correctly signaling that to WordPress, which can make WordPress itself think the connection isn’t secure even though the browser shows HTTPS. The fix is usually setting
$_SERVER['HTTPS']correctly via theHTTP_X_FORWARDED_PROTOheader in your site’s configuration, most hosts handle this automatically, but a custom server setup might not. - Server-level security rules, such as ModSecurity or a custom Nginx/Apache rule, blocking requests to the
wp-json/wp/v2/usersREST endpoint entirely, which would prevent Application Passwords from working even if every plugin-level setting is correct.
If you’ve checked all of the above and it’s still not working, your host’s support team can usually confirm server-level REST API access in a few minutes, that’s a faster path than continuing to guess at plugin settings. Managed hosts in particular (Kinsta, WP Engine, Pressable) often run their own edge-level rules on top of whatever’s configured inside WordPress, so a setting that looks correct in your dashboard can still be overridden further up the stack, worth mentioning explicitly when you open a support ticket so they check that layer rather than just re-verifying your plugin settings.
Should You Even Use Application Passwords, or Is There a Safer Alternative?
For most legitimate use cases, connecting a headless front-end, a Zapier automation, or a mobile app, Application Passwords are the right, WordPress-native tool, and there’s no need to look for a workaround once your site meets the HTTPS baseline. A few practical habits make them meaningfully safer regardless of what Wordfence allows:
- Give every application password a distinct, descriptive name so you can identify and revoke exactly the right one later without guessing.
- Revoke application passwords for tools you’ve stopped using. They don’t expire automatically, an old password for a service you cancelled two years ago is still a live credential unless you manually remove it.
- Where a plugin’s specific integration needs broader access than a single user account should have, consider a dedicated, limited-capability user account for that integration rather than generating an application password under your main admin account.
- For genuinely high-security use cases (financial data, healthcare-adjacent sites), an OAuth-based authentication plugin (such as WP OAuth Server or the WordPress REST API OAuth 1.0a plugin) offers token expiry and scoped permissions that raw Application Passwords don’t provide out of the box, worth the extra setup if your compliance requirements call for it.
Frequently Asked Questions
Does disabling Wordfence’s block also disable my site’s other security features?
No. Enabling Application Passwords through the toggle in Wordfence’s Login Security settings only affects that one specific feature. Your firewall rules, brute-force protection, and malware scanning continue running exactly as configured.
Is it safe to use Application Passwords on a WooCommerce store?
Yes, once HTTPS is properly enforced. Many legitimate WooCommerce integrations (inventory sync tools, mobile order-management apps, headless storefronts) authenticate this way. Follow the same naming and revocation hygiene described above, and consider a dedicated limited-role user for any integration that only needs to read or update orders rather than full admin access.
Can I just disable Wordfence’s REST API protections entirely instead of fixing HTTPS?
You could, but it’s the wrong fix. Turning off the underlying check removes a real protection rather than addressing the actual gap (missing or partial HTTPS). Fixing HTTPS properly is usually a 10-15 minute task with most modern hosts and leaves your site more secure across the board, not just for this one feature.
Why did this suddenly start happening on a site that’s run fine for years?
Usually one of three things: a recent Wordfence update tightened the default check, an SSL certificate silently expired or renewed incorrectly, or a new security plugin was added that’s now conflicting with Wordfence’s existing rules. Check your SSL certificate’s expiry date first, that’s the most common culprit on an otherwise-stable site.
Do Application Passwords expire automatically?
No, not by default in WordPress core. They remain valid indefinitely until manually revoked, which is exactly why the naming and periodic cleanup habits above matter, an old, forgotten application password is a live credential sitting on your site for as long as nobody removes it.
Does a multisite network handle this the same way?
Yes, Application Passwords and Wordfence’s Login Security checks apply per-site within a multisite network the same as a standalone install, though if you’re running Wordfence at the network-admin level, confirm whether the Login Security settings are configured network-wide or need to be set per-subsite before troubleshooting further.
The “Application passwords have been disabled by Wordfence” message looks alarming the first time you see it, but it’s really just Wordfence being appropriately cautious about a genuinely sensitive feature. Once your site properly enforces HTTPS and your Login Security settings are aligned, you’ll be able to use Application Passwords safely, and with the naming and revocation habits above, safely for the long term rather than just until the next security review flags an old, forgotten credential.