Most people have never created one, and yet there is a good chance your site has them. WordPress application passwords are a feature built for apps and scripts that need to talk to your site, and they have a quiet side effect: each one is a way in that does not go through your sign-in page.
This article explains what they are, how to create and revoke one, why they sit outside your usual protections, and how to decide whether to keep them. There is a ready-to-use snippet for turning them off, and a short routine for checking which ones exist.
What Are WordPress Application Passwords?
Application passwords arrived in WordPress 5.6. They are extra, separate passwords that belong to a user account. Each one is 24 characters of letters and digits, and you give it a name that says what it is for, such as "Zapier" or "Mobile app".
The idea is sensible. Before, if a tool wanted to publish posts for you, you had to hand it your real password. Change your password and the tool broke. Hand the password to a tool that gets breached and your whole account is exposed. With an application password, the tool gets its own key. You can see it, name it and cancel it without touching your real password.
The WordPress integration guide for application passwords describes where they work. A request to the REST API sends the username and the application password using HTTP Basic Authentication. XML-RPC accepts them in place of the account password too. They cannot be used to sign in at wp-login.php.
If you want a refresher on those two doors, see our explainer on XML-RPC and the article on WordPress REST API security.
What Uses Them
Typical users of application passwords include:
- Mobile apps that publish to your site.
- Automation tools such as Zapier or Make that create posts or update products.
- Headless setups, where a separate front end reads and writes content through the REST API.
- Command line tools and deploy scripts.
- Some backup, migration and site management services.
If none of those describes your site, there is a good chance you have no use for application passwords at all.
How to Create an Application Password
You do it from the user's profile screen.
- Go to Users, Profile to manage your own, or Users, All Users, Edit for someone else.
- Scroll down to the Application Passwords section.
- Type a name for the app in New Application Password Name. Be specific: "Zapier blog sync" beats "test".
- Click Add New Application Password.
- Copy the password now. WordPress shows it once and cannot show it again.
- Paste it into the app, along with your WordPress username.
Some apps skip the profile screen and use an authorisation flow instead. They send you to a WordPress approval page, you approve the connection, and the password is handed back to the app. It is the same result, only with fewer copy and paste steps.
Two details are worth knowing. The section only appears when the site runs over HTTPS (we cover this below). And the permissions of an application password are exactly those of the user it belongs to, which matters a lot for the next section.
How to Revoke an Application Password
In the same Application Passwords table you will see each password's name, when it was created, when it was last used and the address it was last used from. Each row has a Revoke link. There is also a Revoke all application passwords button.
Revoking a single password cuts off that app and nothing else. The user's normal password and sessions are untouched. That makes it a handy tool when one integration is retired or a contractor's setup leaves.
Pro tip: If you lose a laptop or fire an integration vendor, revoke their application password first and change the account password second. The application password is the one that can keep working without anyone signing in.
The Security Trade-Off
Here is where it gets interesting. Application passwords exist so that a program can sign in without a person present. That is the feature, and it is also the risk.
They Skip the Sign-In Page
Everything you build around the sign-in page, such as a hidden login address, a CAPTCHA or a lockout after failed tries, protects the page. An application password does not use that page. It goes straight to the REST API or XML-RPC.
They Skip Two-Factor
A program cannot type a six-digit code from your phone, so application passwords do not ask for one. The WordPress core team noted the same thing in its integration guide: because apps use their own credential, the account password no longer needs to be exposed to non-interactive methods. That is good for the account password. It also means that a leaked application password gives full access as that user with no second step. Stack Guard's remote access documentation says it plainly: application passwords let apps sign in without the normal sign-in page, and they skip two-factor sign-in.
So a user with two-factor turned on, strong password and a locked-down login can still have an exposed back door if they once created an application password and pasted it somewhere careless.
They Inherit the User's Role
An application password is as powerful as the account that owns it. One created by an Administrator can, through the REST API, do what an Administrator can do. That is why the person who creates them matters. If a tool only needs to publish posts, create it under an Author account, not an Administrator. Our article on WordPress user roles explains how to choose.
They Are Easy to Forget
WordPress application passwords are easy to lose track of. Nobody remembers the Zapier connection from 2023. It sits there. The profile table shows a last-used date, which helps you spot the dead ones, but only if you look.
Key takeaway: An application password is a long-lived key that works without two-factor, the sign-in page or a person at the keyboard. Keep the ones you need, and remove everything else.
Do WordPress Application Passwords Need HTTPS?
By default, yes. The core integration guide says application passwords are available by default only on sites served over HTTPS, because otherwise the password could be seen by anyone on the network between the app and your server.
You can override that with a filter, but you should not on a live site. If your site is still on plain HTTP, fix that first. Our article on how to force HTTPS in WordPress covers it.
Keep or Disable WordPress Application Passwords?
Use this simple rule for your WordPress application passwords.
| Your situation | What to do |
|---|---|
| Nothing connects to your site by app, script or automation | Disable application passwords |
| One or two known integrations use them | Keep them, use a low-privilege account, and review quarterly |
| A headless site or mobile app depends on them | Keep them, over HTTPS only, and treat each one like a production secret |
| You inherited the site and nobody knows | Audit first (see below), then decide |
There is no prize for leaving a feature on just because it exists. Turning off what you do not use is the cheapest hardening available, and it is the reason our hardening checklist lists remote access methods near the top.
How to Disable Application Passwords With a Filter
WordPress gives you one filter for this. Returning false from wp_is_application_passwords_available switches the feature off completely: the profile section disappears and requests using application passwords are refused.
<?php
/**
* Plugin Name: Disable Application Passwords
*/
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
add_filter( 'wp_is_application_passwords_available', '__return_false' );
Save that as a file in wp-content/mu-plugins/ (create the folder if it does not exist) and it loads on every request and cannot be turned off from the admin by mistake.
If you want application passwords for some people only, there is a second filter, wp_is_application_passwords_available_for_user, which receives the user. Return false for everyone except the accounts that need it:
add_filter( 'wp_is_application_passwords_available_for_user', function ( $available, $user ) {
return user_can( $user, 'edit_posts' ) ? $available : false;
}, 10, 2 );
That version keeps the feature for people who can edit posts and removes it for everyone else.
Disabling Them From the Settings Screen
If you would rather click than code, Stack Guard Pro has a Disable application passwords switch under the Hardening tab, in the Attack surface section. It does exactly what the snippet above does by returning false from the same filter. Free covers the neighbouring switches: XML-RPC, pingbacks and trackbacks, the code editors and user enumeration. The Hardening feature page lists them all.
Before you switch it on, check the warning that follows.
Check first: Turning application passwords off breaks anything that uses them. Make a list of the integrations that still work, test them afterwards, and be ready to turn the switch back off.
How to Audit Which Application Passwords Exist
Core does not give you a single screen that lists every application password on the site. You have to look at the users. A tidy routine looks like this.
- Open Users and note everyone with a role that could be used for an integration, starting with Administrators and Editors.
- Open each profile and scroll to Application Passwords. Write down the name, last used date and address of each row.
- Revoke any that you do not recognise, that have never been used, or that have not been used for months.
- For the rest, check that the user who owns it has the lowest role the integration needs.
- Put a reminder in your calendar to repeat this each quarter.
If you have many users, WP-CLI can list them: wp user application-password list <user> shows the passwords for one user, and a short loop covers the rest. Ask your host or developer if you are not sure how to run it.
On a site you do not control, such as a client's, make this part of your onboarding. Our WordPress security audit article puts it in the bigger picture.
Related Habits That Work Alongside This
Disabling or auditing WordPress application passwords closes one door. The doors next to it matter just as much.
- Turn on two-factor for every account that can publish or manage the site. Stack Guard's two-factor feature works with authenticator apps and email codes. The reminder to take from this article is that two-factor protects people, not application passwords.
- Shorten sessions. Cookies stay valid for a long time. Our article on WordPress auto logout explains how to set session length sensibly.
- Watch for new administrators. If an attacker with an application password uses it to create another admin, the Users screen is where you will see it.
- Block what you do not use. XML-RPC is the other door for remote access, and it is easy to switch off when nothing needs it.
None of this means application passwords are bad. They are a well-designed improvement over sharing your real password. They just belong in the category of "useful if you use them, risky if you forgot you have them".