What are Application Passwords in WordPress?

Application Passwords are 24 character credentials introduced in WordPress 5.6 (December 2020) that allow external applications to authenticate against the WordPress REST API and XML RPC without exposing the user main login password. Each Application Password is tied to one user and one named application, can be revoked individually from the user profile, and is sent over HTTPS using HTTP Basic Authentication. They replace the older insecure pattern of storing the main WordPress password inside third party apps and are now the recommended way to integrate WordPress with mobile apps, deployment scripts, headless frontends, backup tools and AI agents.

Why did WordPress introduce Application Passwords?

Before WordPress 5.6, every REST API or XML RPC integration that needed write access had to use the main account password (Basic Auth) or rely on third party plugins like JWT Auth or OAuth. Both options had problems: the main password gave full control including theme and plugin editing, and a leaked credential meant a full account takeover. Application Passwords solve this by issuing per app credentials that can be revoked instantly without changing the user password or breaking other integrations.

How do Application Passwords work?

A logged in user opens Users » Profile in the WordPress admin, scrolls to the section "Application Passwords", enters a name like "iPhone App" or "Backup Script" and clicks Add New Application Password. WordPress generates a 24 character token displayed once in the format xxxx xxxx xxxx xxxx xxxx xxxx (spaces are optional and ignored on submit). The token is stored hashed in wp_usermeta under the key _application_passwords and used together with the user login in HTTP Basic Auth:

curl -u username:xxxxxxxxxxxxxxxxxxxxxxxx \
     https://example.com/wp-json/wp/v2/posts

Or with a JavaScript fetch call from a headless frontend:

const token = btoa('username:xxxxxxxxxxxxxxxxxxxxxxxx');
fetch('https://example.com/wp-json/wp/v2/posts', {
  headers: { 'Authorization': 'Basic ' + token }
});

What are typical use cases for Application Passwords?

• Mobile apps like the official WordPress iOS and Android app.
• Headless frontends built with Next.js, Astro, SvelteKit or Nuxt that pull content from /wp-json/wp/v2/.
• CI/CD deployment scripts that publish posts, update menus or trigger cache purges.
• Backup and migration tools like UpdraftPlus Remote, ManageWP, MainWP.
• AI content workflows where Zapier, Make, n8n or a custom GPT agent posts drafts to WordPress.
• WooCommerce inventory sync from an ERP or PIM system.

How do I create an Application Password step by step?

1. Log into WordPress as the user whose account the integration will act as. Each Application Password inherits the role and capabilities of its user, so create a dedicated user for the integration if possible.
2. Go to Users » Profile (your own profile) or Users » All Users » Edit for another account.
3. Scroll to Application Passwords.
4. Enter a descriptive name. Use a name that identifies the app and the device, for example Zapier Production or Backup Server eu01.
5. Click Add New Application Password.
6. Copy the 24 character token immediately. It is shown exactly once and stored only as a hash afterwards.
7. Paste the token into the external app together with your WordPress username.

How do I revoke or audit Application Passwords?

On the same profile screen, each Application Password shows when it was created and when it was last used. Click Revoke next to a single entry, or Revoke all application passwords to invalidate every token at once. Revoking takes effect immediately, no cache invalidation needed. Reviewing the "Last Used" date every quarter is a good way to spot forgotten integrations.

Are Application Passwords secure?

Yes, when used over HTTPS. Each token has roughly 144 bits of entropy (24 base32 characters), is stored hashed with phpass and is sent only in the HTTP Authorization header. Risks to be aware of:

• HTTPS is mandatory. WordPress refuses Application Passwords on plain HTTP by default unless WP_ENVIRONMENT_TYPE is local.
• Server side disclosure. If an attacker can read wp_usermeta, the hashed token is useless on its own, but a tampered plugin could log the raw header.
• No scope or expiration. A token inherits all capabilities of its user and never expires. Use a dedicated user with the minimum role needed (Author instead of Administrator).
• Disabled by default in some hardening plugins like iThemes Security or Solid Security. Re enable explicitly when needed.

How are Application Passwords different from OAuth, JWT or API Keys?

For most WordPress integrations Application Passwords are the right default. Use OAuth 2.0 only if you need scopes, refresh tokens or a multi tenant SaaS scenario.

How do I disable Application Passwords entirely?

Add to a custom plugin or functions.php:

add_filter( 'wp_is_application_passwords_available', '__return_false' );

Or restrict per user:

add_filter( 'wp_is_application_passwords_available_for_user', function ( $available, $user ) {
    if ( user_can( $user, 'manage_options' ) ) {
        return false; // disable for administrators
    }
    return $available;
}, 10, 2 );

What InspectWP checks

InspectWP reports the WordPress REST API availability and flags the /wp-json/wp/v2/users endpoint when it exposes user data without authentication. Application Passwords themselves are not transmitted in HTML, so they are not part of a crawl, but the REST API status helps you decide whether to keep Application Passwords enabled.