Application Passwords Missing in WordPress Profile? 5 Fixes

You opened the user profile screen in WordPress, scrolled to the bottom, and the Application Passwords section is not there. No form to create a credential, no message explaining why, just nothing. If your Application Passwords are missing from your WordPress profile, the feature is being blocked by one of five specific conditions. This guide covers each one with the exact confirmation check and the code to fix it.

If you are trying to connect an external tool like a content automation plugin or a deployment script, this is usually the first blocker. The feature exists in WordPress core, but several conditions can hide it entirely. We have hit every one of these while building ClearPost, which authenticates to WordPress through the REST API using Application Passwords. The diagnostic order below mirrors how we troubleshoot when the section disappears. For broader REST API connection failures that go beyond authentication, our REST API disabled troubleshooting guide covers routing, server rules, and firewall blocks.

Why the Section Is Missing

WordPress decides whether to show the Application Passwords section through a chain of two functions. wp_is_application_passwords_supported() checks whether the site is on HTTPS or running in a local environment. wp_is_application_passwords_available() takes that result and passes it through the wp_is_application_passwords_available filter, which any plugin or theme can override. A separate function, wp_is_application_passwords_available_for_user(), adds a per-user filter on top. The profile screen shows the section if the user has access or if the site does not support the feature (to display the “HTTPS required” message). If the site supports the feature but a filter blocks it, the section vanishes with no explanation.

One more prerequisite: Application Passwords were introduced in WordPress 5.6 (released December 8, 2020). If your site runs an older version, the feature does not exist at all. Check your version under Dashboard > Updates or run wp core version with WP-CLI. If you are below 5.6, updating WordPress core is the only fix.

The table below maps your symptom to the likely cause and where to jump in this guide.

Symptom	Likely Cause	Jump To
Section shows “HTTPS required” message, no form	Site not on SSL	Cause 1
Site has SSL certificate, but WordPress sees HTTP	Reverse proxy terminates SSL before WordPress	Cause 2
Site is on HTTPS, section is gone with no message	wp_is_application_passwords_available filter set to false	Cause 3
Local or staging site, no SSL, section missing	WP_ENVIRONMENT_TYPE not set to “local”	Cause 4
Section missing for one user, visible for others	Per-user filter or capability restriction	Cause 4
Section does not exist anywhere on the profile page	WordPress version older than 5.6	Update WordPress core

Cause 1: The Site Is Not on HTTPS

This is the most common cause. WordPress hides the Application Passwords feature entirely on sites served over plain HTTP. The reasoning is straightforward: Application Passwords use HTTP Basic Authentication, which transmits credentials in a header that can be intercepted without encryption. WordPress core will not enable the feature unless is_ssl() returns true or the environment is explicitly set to local. On a non-HTTPS site, the profile screen shows a message saying the feature requires HTTPS instead of the password creation form.

Symptom: The Application Passwords section is visible on the profile page but shows “The application password feature requires HTTPS, which is not enabled on this site” instead of the form to create a password.

How to confirm: Check whether WordPress sees the site as HTTPS. You can do this with WP-CLI:

wp eval 'var_dump( is_ssl() );'

If the output is bool(false), WordPress does not detect SSL. Also check the site URL in Settings > General. If either the WordPress Address or Site Address starts with http:// instead of https://, that confirms the issue. The is_ssl() function checks $_SERVER['HTTPS'] and port 443 to determine if the request is encrypted.

The fix: Install an SSL certificate and update both URL fields in Settings > General to use https://. Most hosts offer free Let’s Encrypt certificates through their dashboard. After installing the certificate, you may also need to add a redirect from HTTP to HTTPS in your server configuration or .htaccess file:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

After switching to HTTPS, revisit the profile page. The Application Passwords form should appear. If it does, the HTTPS requirement was the only blocker. If the site has an SSL certificate but WordPress still reports is_ssl() as false, you are likely behind a reverse proxy. Skip to Cause 2.

Cause 2: Reverse Proxy Terminating SSL

Your site has an SSL certificate and loads over HTTPS in the browser, but WordPress still thinks it is on HTTP. This happens when a reverse proxy, load balancer, or CDN terminates the SSL connection before forwarding the request to WordPress over plain HTTP internally. The proxy handles the encryption, but WordPress never sees it. Since is_ssl() checks $_SERVER['HTTPS'], which the proxy does not set, the function returns false and Application Passwords stay hidden.

This is the most frustrating variant of Cause 1 because the site clearly works over HTTPS in the browser, but WordPress insists it is HTTP. The symptom looks identical to Cause 1, but the fix is different.

Symptom: The site loads over HTTPS in the browser with a valid certificate, but is_ssl() returns false and the Application Passwords section shows the “HTTPS required” message.

How to confirm: Run the same WP-CLI check from Cause 1:

wp eval 'var_dump( is_ssl() );'

If this returns bool(false) despite the site loading over HTTPS, check whether the request reaches PHP with the X-Forwarded-Proto header. The WordPress HTTPS administration guide documents this exact scenario. You can verify the header is present with:

wp eval 'var_dump( $_SERVER["HTTP_X_FORWARDED_PROTO"] ?? "not set" );'

If the output contains https, the proxy is forwarding the protocol header but WordPress is not reading it.

The fix: Add the following to wp-config.php, above the require_once( ABSPATH . 'wp-settings.php' ); line. This tells WordPress to treat the request as HTTPS when the proxy reports it was made over HTTPS:

define( 'FORCE_SSL_ADMIN', true );

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
 && false !== strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' )
) {
 $_SERVER['HTTPS'] = 'on';
}

The strpos check handles cases where the header contains a comma-separated list like http,https, which happens when requests pass through multiple proxies. The placement matters: this code must run before WordPress loads its settings, so put it near the top of wp-config.php alongside your other define() statements.

You also need to make sure your reverse proxy is actually sending the header. For Nginx, the proxy configuration should include:

location / {
 proxy_pass http://wordpress-origin;
 proxy_set_header Host $http_host;
 proxy_set_header X-Forwarded-Proto $scheme;
}

The $scheme variable resolves to https when the original request was HTTPS. After adding both the proxy header and the wp-config.php fix, reload Nginx and revisit the profile page.

If your origin is directly reachable by the public internet (not only through the proxy), do not blindly trust the X-Forwarded-Proto header. An attacker could send a fake header to trick WordPress into treating HTTP as HTTPS. Restrict the header at the proxy level so it is always overwritten before reaching the origin.

Cause 3: A Filter Disabling the Feature

The site is on HTTPS, the section should be visible, but it is gone with no message at all. This is the signature of a filter override. A security plugin, a must-use plugin, or custom code in your theme has hooked wp_is_application_passwords_available and returned false. WordPress applies this filter on top of the SSL check, so even on a fully HTTPS site, a single __return_false callback erases the entire section.

Symptom: The site is on HTTPS (or the reverse proxy fix from Cause 2 is in place), but the Application Passwords section is completely absent from the profile page. No form, no “HTTPS required” message, nothing. This distinguishes a filter issue from an HTTPS issue: the HTTPS problem shows a message, the filter problem shows nothing.

How to confirm: Search your codebase for the filter:

grep -r "wp_is_application_passwords_available" wp-content/

Check your active theme’s functions.php, any mu-plugins in wp-content/mu-plugins/, and active plugin files. Look for any of these patterns:

add_filter( 'wp_is_application_passwords_available', '__return_false' );

Security plugins are the most common source. Some hardening plugins disable Application Passwords by default as part of their “disable XML-RPC and REST API authentication” features. If you have Wordfence, Solid Security, or a similar plugin installed, check their settings for an option to disable Application Passwords or restrict API authentication. The fastest confirmation is to deactivate all plugins and check whether the section reappears. If it does, reactivate plugins one by one until the section disappears again to identify the culprit.

The fix: Remove or override the filter. If you control the code, delete the add_filter call or change __return_false to __return_true. If the filter is in a plugin you cannot edit, override it with a higher-priority callback in a must-use plugin:

// In wp-content/mu-plugins/enable-app-passwords.php
add_filter( 'wp_is_application_passwords_available', '__return_true', 999 );

The priority 999 ensures this callback runs after the restrictive filter. If the plugin’s filter runs at the default priority (10), your override at 999 will take precedence. If the plugin also uses a high priority, you may need to remove its callback explicitly:

// Replace with the actual callback function name from the plugin
remove_filter( 'wp_is_application_passwords_available', 'plugin_callback_name' );

To find the callback name, search the plugin’s source for add_filter( 'wp_is_application_passwords_available' and note the function name in the second argument.

Cause 4: Environment Type or User Capability

Environment Type Not Set to “local”

If you are developing on a local or staging site without HTTPS, WordPress can still enable Application Passwords if you set the environment type to local. The catch: WordPress specifically requires local, not development. This is a known source of confusion. The profile screen message says “If this is a development website you can set the environment type accordingly,” but setting WP_ENVIRONMENT_TYPE to development does not enable the feature. Only local works.

Symptom: Local or staging site without SSL. The Application Passwords section shows the “HTTPS required” message, or the section is absent entirely if a filter is also active.

How to confirm: Check the environment type:

wp eval 'var_dump( wp_get_environment_type() );'

If the output is string(10) "production" or string(11) "development", that is the problem. The WordPress function reference confirms that Application Passwords are available on SSL sites or local environments only.

The fix: Add this to wp-config.php, above the require_once line:

define( 'WP_ENVIRONMENT_TYPE', 'local' );

After saving, the Application Passwords section should appear on the profile page. Use this only on local or development sites, never on production. On production, fix HTTPS instead.

User Capability Restrictions

Application Passwords have fine-grained capabilities: create_app_password, list_app_passwords, read_app_password, edit_app_password, delete_app_password, and delete_app_passwords. By default, all of these map to the edit_user capability, which administrators and editors have. A per-user filter, wp_is_application_passwords_available_for_user, can also restrict the feature to specific roles or users. If the section is visible for one user but missing for another, a capability or per-user filter is the cause.

Symptom: The Application Passwords section appears for the administrator but is missing when viewing or editing a different user’s profile, or it is missing for a specific role.

How to confirm: First, check whether the per-user filter is active:

grep -r "wp_is_application_passwords_available_for_user" wp-content/

Second, check the user’s capabilities. For the profile owner to create Application Passwords, they need the edit_user capability (which maps to create_app_password). You can check this with WP-CLI:

wp cap list <username> | grep edit_user

If the command returns nothing, the user lacks the capability. This is common for roles like Subscriber or Contributor, which do not have edit_user by default.

The fix: If a per-user filter is blocking access, either remove the filter or modify it to allow the specific user. If the issue is a missing capability, add it to the user’s role:

// In functions.php or a must-use plugin
$role = get_role( 'contributor' );
if ( $role && ! $role->has_cap( 'edit_user' ) ) {
 $role->add_cap( 'edit_user' );
}

Be cautious: granting edit_user gives the role the ability to edit other users’ profiles, not just create Application Passwords. For tighter control, map the specific Application Password capabilities to a custom role instead of broadening edit_user.

If a plugin has hooked wp_is_application_passwords_available_for_user to restrict access to certain roles, you can override it:

add_filter( 'wp_is_application_passwords_available_for_user', function( $available, $user ) {
 // Allow for a specific user ID
 if ( $user instanceof WP_User && 42 === $user->ID ) {
 return true;
 }
 return $available;
}, 10, 2 );

A Snippet to Diagnose It in 30 Seconds

Instead of checking each cause individually, drop this snippet into a must-use plugin or your theme’s functions.php. It outputs an admin notice on every admin page with every relevant diagnostic value: WordPress version, SSL status, environment type, and the result of each Application Passwords availability check. If the feature is blocked, the output tells you exactly which check failed and which cause to investigate.

add_action( 'admin_notices', function() {
 // Check if the feature exists at all
 if ( ! function_exists( 'wp_is_application_passwords_available' ) ) {
 echo '<div class="notice notice-error"><p>Application Passwords requires WordPress 5.6+. Current version: ' . esc_html( get_bloginfo( 'version' ) ) . '</p></div>';
 return;
 }

 $is_ssl = is_ssl();
 $env_type = function_exists( 'wp_get_environment_type' ) ? wp_get_environment_type() : 'unknown';
 $supported = wp_is_application_passwords_supported();
 $available = wp_is_application_passwords_available();
 $user_avail = wp_is_application_passwords_available_for_user( get_current_user_id() );

 $diag = sprintf(
 "<strong>Application Passwords Diagnostic</strong><br>
 WordPress version: %s<br>
 is_ssl(): %s<br>
 Environment type: %s<br>
 wp_is_application_passwords_supported(): %s<br>
 wp_is_application_passwords_available(): %s<br>
 wp_is_application_passwords_available_for_user(): %s",
 get_bloginfo( 'version' ),
 $is_ssl ? 'true (HTTPS detected)' : 'false (not HTTPS)',
 esc_html( $env_type ),
 $supported ? 'true' : 'false -> check HTTPS or set WP_ENVIRONMENT_TYPE to local',
 $available ? 'true' : 'false -> a filter is disabling it (see Cause 3)',
 $user_avail ? 'true' : 'false -> per-user filter or capability issue (see Cause 4)'
 );

 echo '<div class="notice notice-info"><p>' . $diag . '</p></div>';
} );

Here is how to read the output:

• If is_ssl() is false: you have an HTTPS issue. Go to Cause 1 or Cause 2.
• If is_ssl() is true but wp_is_application_passwords_supported() is false: something is wrong with the SSL detection logic. Check for a custom is_ssl filter override.
• If wp_is_application_passwords_supported() is true but wp_is_application_passwords_available() is false: a filter is disabling the feature. Go to Cause 3.
• If wp_is_application_passwords_available() is true but wp_is_application_passwords_available_for_user() is false: a per-user filter or capability issue. Go to Cause 4.
• If the function does not exist at all: your WordPress version is below 5.6. Update core.

Remove the snippet after diagnosing. It runs on every admin page load and is not meant for permanent use.

If you are connecting an external content tool to WordPress and hitting authentication issues beyond the Application Passwords section itself, the problem may be at the REST API layer. The official Application Passwords troubleshooting guide covers header stripping and client configuration. For REST API routing and firewall issues that block authenticated requests entirely, our REST API disabled guide walks through the full diagnostic chain. And if you are evaluating content automation tools that need Application Passwords to publish, our WordPress plugin that writes blog posts guide covers how these integrations work end to end.

Once the Application Passwords section is visible and you can generate a credential, the authentication pipeline is straightforward: create a password, copy it immediately (it is shown only once), and pass it to your tool as Basic Auth credentials. If you are automating content publishing with ClearPost, the plugin handles this authentication layer internally. AI drafts the posts, you approve every one before it goes live. No manual API debugging, no server configuration to troubleshoot. Try ClearPost free for 7 days and see what a working content pipeline looks like without the integration headaches.

Frequently Asked Questions

Why is the Application Passwords section not showing on my WordPress profile?

The section is hidden when one of five conditions is true: the site is not on HTTPS, a reverse proxy terminates SSL before WordPress sees it, the wp_is_application_passwords_available filter is set to false by a plugin, the environment type is not set to local on a non-HTTPS site, or the user lacks the edit_user capability. The section also does not exist at all on WordPress versions older than 5.6.

Does WordPress require HTTPS for Application Passwords?

Yes. WordPress hides the Application Passwords feature on sites served over plain HTTP because the credentials are transmitted via Basic Auth headers, which can be intercepted without encryption. The function wp_is_application_passwords_supported() returns true only if is_ssl() returns true or the environment type is set to local.

How do I enable Application Passwords behind a reverse proxy or load balancer?

Add code to wp-config.php that checks the HTTP_X_FORWARDED_PROTO header and sets $_SERVER[‘HTTPS’] to ‘on’ when the header contains ‘https’. This tells WordPress the original request was encrypted even though the proxy forwarded it internally over HTTP. Place the code above the require_once line for wp-settings.php.

Can a security plugin hide the Application Passwords section?

Yes. Security plugins can hook the wp_is_application_passwords_available filter and return false, which removes the section entirely from the profile page with no message. The fastest way to confirm is to deactivate all plugins and check if the section reappears. If it does, reactivate one by one to find the culprit.

What WordPress version do I need for Application Passwords?

Application Passwords were introduced in WordPress 5.6, released on December 8, 2020. If your site runs an older version, the feature does not exist and no configuration change will make it appear. Update WordPress core to 5.6 or later to get the feature.