Fix: Application Password Feature Requires HTTPS Error

The application password feature requires HTTPS error means WordPress cannot confirm your site is encrypted, so it disabled Application Passwords for security. The most common cause is no SSL certificate. Fix it by installing SSL and updating your site URLs to https:// in Settings, General. If you are on a local development environment, add define( 'WP_ENVIRONMENT_TYPE', 'local' ) to wp-config.php above the require_once line. Do not use that constant on production to bypass the check; the correct fix on production is always HTTPS.

If you are connecting an external content automation tool like ClearPost to WordPress via the REST API, this is typically the first authentication blocker you hit. Application Passwords are the standard credential type for external integrations, and WordPress will not even display the password creation form until this error is resolved.

Symptom	Likely Cause	Fix
Site URL starts with http://	No SSL certificate installed	Install SSL, update URLs to https://
Site loads HTTPS in browser, error still appears	Reverse proxy terminates SSL before WordPress	Add X-Forwarded-Proto check to wp-config.php
Developing on localhost, no SSL, error appears	WP_ENVIRONMENT_TYPE not set to local	Add define( ‘WP_ENVIRONMENT_TYPE’, ‘local’ )
Set WP_ENVIRONMENT_TYPE to development, still fails	WordPress requires local, not development	Change the constant value to local
HTTPS is working, Application Passwords still missing	Plugin filter or WordPress below 5.6	See: Where These Fixes Do Not Apply

What Does the “Application Password Feature Requires HTTPS” Error Mean?

WordPress shows this error on the user profile screen at /wp-admin/profile.php when the function wp_is_application_passwords_supported() returns false. That function, defined in wp-includes/user.php, contains exactly one line of logic:

function wp_is_application_passwords_supported() {
 return is_ssl() || 'local' === wp_get_environment_type();
}

If is_ssl() returns false and wp_get_environment_type() returns anything other than local, the function returns false. WordPress then displays this message in place of the Application Passwords creation form: “The application password feature requires HTTPS, which is not enabled on this site.” Below that, it adds: “If this is a development website you can set the environment type accordingly to enable application passwords.” The WordPress developer reference confirms this behavior.

The function runs inside a chain. wp_is_application_passwords_supported() checks the SSL and environment conditions. wp_is_application_passwords_available() passes that result through the wp_is_application_passwords_available filter, which plugins can override. wp_is_application_passwords_available_for_user() adds a per-user filter on top. The profile screen calls the last function to decide whether to show the form or the error message.

Why Does WordPress Disable Application Passwords Without HTTPS?

Application Passwords use HTTP Basic Authentication. The credentials are sent as a base64-encoded string in the Authorization header on every API request. Base64 is not encryption. Anyone on the same network who can inspect the traffic can decode the credential string in seconds. On a site served over plain HTTP, every REST API request carrying an Application Password transmits that credential in plaintext.

WordPress core made a deliberate security decision: the feature is disabled on non-HTTPS sites unless the environment is explicitly local. This is not a bug or an oversight. It is a guard against credential interception. The check lives in wp_is_application_passwords_supported(), which was introduced in WordPress 5.6 (released December 8, 2020) alongside Application Passwords themselves. The function was later separated from the availability filter in changeset 52398 to ensure the HTTPS requirement message always displays correctly, even when a plugin filters availability.

How Do You Fix a Site With No SSL Certificate?

This is the most common cause. If your site URL in Settings, General starts with http://, you do not have SSL, and Application Passwords are disabled by design. The fix is to install an SSL certificate and update both URL fields.

Step 1: Install an SSL certificate. Most hosting providers offer free Let’s Encrypt certificates through their control panel. If you have shell access, you can install one yourself using certbot. The certificate must be valid and trusted by browsers, not self-signed.

Step 2: Update the WordPress Address (URL) and Site Address (URL) fields in Settings, General to use https:// instead of http://. Both fields must use https.

Step 3: Add a redirect from HTTP to HTTPS in your .htaccess file (Apache) or server block (Nginx) so old HTTP links do not break:

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

After these changes, reload your site over HTTPS and navigate to Users, Profile. The Application Passwords section should now show the password creation form instead of the error message. If the section is still missing, skip to Where These Fixes Do Not Apply.

How Do You Fix SSL Detection Behind a Reverse Proxy?

Your site loads over HTTPS in the browser with a valid certificate, but WordPress still shows the error. This happens when a reverse proxy, load balancer, or CDN terminates the TLS connection and forwards the request to your origin server over plain HTTP. WordPress only sees the internal HTTP hop, so is_ssl() returns false.

Confirm this with WP-CLI:

wp eval 'var_dump( is_ssl() );'

If the output is bool(false) despite the site loading over HTTPS, you are behind a proxy. The fix is to add a conditional block to wp-config.php that checks the X-Forwarded-Proto header and sets $_SERVER['HTTPS'] to on when the proxy reports the original request was HTTPS:

define( 'FORCE_SSL_ADMIN', true );

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

Place this block above the line that reads /* That's all, stop editing! Happy publishing. */ and above the require_once ABSPATH . 'wp-settings.php'; line. If the code runs after WordPress loads, it has no effect. The strpos check instead of strict equality handles cases where requests pass through multiple proxies and the header contains a comma-separated list like http,https.

You also need to confirm your proxy is actually sending the header. For Nginx, the proxy location block must include:

proxy_set_header X-Forwarded-Proto $scheme;

After applying both the proxy header and the wp-config.php fix, reload Nginx with sudo systemctl reload nginx and check the profile page again. For the full reverse proxy SSL diagnostic chain, including Cloudflare Flexible SSL, CloudFront, and other CDN-specific headers, see our is_ssl() reverse proxy fix guide.

How Do You Set WP_ENVIRONMENT_TYPE to local for Development?

If you are developing on localhost or a staging site without HTTPS, you can enable Application Passwords by setting the environment type to local. Add this line to wp-config.php, above the require_once line:

define( 'WP_ENVIRONMENT_TYPE', 'local' );

After saving, reload the profile page. The Application Passwords form should appear. The value must be exactly local. WordPress defaults to production when the constant is not defined or is set to an invalid value.

The “development” vs “local” Confusion

The error message on the profile page says: “If this is a development website you can set the environment type accordingly to enable application passwords.” That wording leads developers to set WP_ENVIRONMENT_TYPE to development. It does not work. The wp_is_application_passwords_supported() function checks specifically for the string local, not development. This is a known issue tracked in WordPress Trac ticket #57388, where the reporter flagged the misleading message. As of the current WordPress release, the message still says “development” but the code still requires local.

Confirm your current environment type with WP-CLI:

wp eval 'var_dump( wp_get_environment_type() );'

If the output is string(11) "development" or string(10) "production", that is why Application Passwords are still disabled. Change the constant to local and reload.

Why Must You Not Use WP_ENVIRONMENT_TYPE to Bypass HTTPS in Production?

Setting WP_ENVIRONMENT_TYPE to local on a production site is a security vulnerability, not a workaround. The constant makes wp_is_application_passwords_supported() return true regardless of whether is_ssl() passes. Application Passwords then become available, and every REST API request transmits the credential as a base64-encoded string in the Authorization header over whatever protocol the site uses. On a production site without HTTPS, that means plaintext credentials on every request.

The threat model is specific and real. Anyone on the same network path, between the API client and the WordPress server, can capture the Authorization header and decode the credential. This includes anyone on the same WiFi network as the API client, anyone with access to an intermediate proxy, or anyone who can intercept traffic at the hosting provider’s network level. The base64 encoding provides zero protection. It is reversible by design.

Setting local also has side effects beyond Application Passwords. WordPress core and third-party plugins use the environment type to control caching behavior, debug output, and other production-sensitive settings. Running a production site with local can disable caching, expose debug information, and trigger development-mode behavior in plugins that assume local means a trusted single-user environment.

The correct fix on production is always: install an SSL certificate, serve the site over HTTPS, and let is_ssl() return true natively. If you are behind a reverse proxy, add the X-Forwarded-Proto check described above. Do not set WP_ENVIRONMENT_TYPE to local on any site that is accessible to the public internet.

How Do You Confirm Application Passwords Are Fixed?

Run these checks in order. If all three pass, the feature is working.

Check 1: Verify SSL detection or environment type. Run the WP-CLI command that matches your fix:

wp eval 'var_dump( is_ssl() );'
wp eval 'var_dump( wp_get_environment_type() );'

If you installed SSL or fixed the reverse proxy, is_ssl() should return bool(true). If you set the environment type for local development, wp_get_environment_type() should return string(5) "local". One of these must be true for the feature to work.

Check 2: Verify the profile page shows the form. Navigate to Users, Profile in wp-admin. Scroll to the Application Passwords section. You should see a form to create a new application password, not the “HTTPS required” error message. If the section is missing entirely, a plugin filter or WordPress version issue is the cause. See our Application Passwords missing guide for that diagnostic path.

Check 3: Authenticate via the REST API. Create an Application Password in the profile, copy it immediately (WordPress shows it only once), and test with curl:

curl -i --user "USERNAME:APPLICATION_PASSWORD" https://example.com/wp-json/wp/v2/users/me

A successful response returns HTTP 200 with a JSON body containing your user data. A 401 response means the credentials were not received or were invalid. A 403 response means the credentials were accepted but the user lacks permissions for that endpoint. If you are still hitting 401 or 403 after confirming the Application Passwords form is visible, the problem has moved to the authentication or permission layer. Our Application Passwords troubleshooting guide covers header stripping, security plugin interference, and role capability issues in detail.

Where Do These Fixes Not Apply?

WordPress Version Below 5.6

Application Passwords were introduced in WordPress 5.6. If your site runs an older version, the feature does not exist and no configuration change will make it appear. Check your version under Dashboard, Updates or run wp core version. The only fix is updating WordPress core.

A Plugin Filter Is Overriding Availability

Even when is_ssl() returns true and the environment is correct, a security plugin or custom code can hook wp_is_application_passwords_available and return false. This removes the section entirely from the profile page, with no error message. Search your codebase:

grep -r "wp_is_application_passwords_available" wp-content/

If you find add_filter( 'wp_is_application_passwords_available', '__return_false' ), that is the cause. Remove the filter or override it with a higher-priority callback. This is a different problem from the HTTPS error, and the SSL and environment fixes described above will not resolve it.

Hosting Providers That Strip the Authorization Header

Some managed WordPress hosts strip the Authorization header at the platform level before the request reaches PHP. The Application Passwords form may be visible, SSL may be working, but every authenticated request returns 401 because the credential never arrives. This is a server configuration issue, not an HTTPS issue. Contact your host and ask whether they pass the Authorization header to PHP. For the full diagnostic chain, see our REST API disabled troubleshooting guide.

No SSL Certificate at All

If the site genuinely has no SSL certificate, the error is correct behavior, not a bug. Setting WP_ENVIRONMENT_TYPE to local on a production site without SSL does not fix the underlying problem. It makes credentials interceptable. The only legitimate fix is to install a certificate. Let’s Encrypt provides free certificates, and most hosts offer one-click SSL installation.

Frequently Asked Questions

What does the “application password feature requires HTTPS” error mean?

WordPress displays this error when wp_is_application_passwords_supported() returns false. That function checks two conditions: is_ssl() must return true, or wp_get_environment_type() must return local. If neither condition is met, WordPress hides the Application Passwords form and shows the HTTPS requirement message instead.

How do you fix a site with no SSL certificate?

Install an SSL certificate (Let’s Encrypt provides free ones), update both the WordPress Address and Site Address in Settings, General to use https://, and add an HTTP-to-HTTPS redirect in your .htaccess or Nginx config. After these changes, the Application Passwords form should appear on the user profile page.

How do you set WP_ENVIRONMENT_TYPE to local for development?

Add define( ‘WP_ENVIRONMENT_TYPE’, ‘local’ ) to wp-config.php above the require_once line. The value must be exactly local, not development. WordPress says ‘development’ in the error message but the code checks specifically for the string local. This is a known issue tracked in WordPress Trac ticket #57388.

Why must you not use WP_ENVIRONMENT_TYPE to bypass HTTPS in production?

Setting WP_ENVIRONMENT_TYPE to local on production makes Application Passwords available without encryption. The credentials are transmitted as base64-encoded strings in the Authorization header, which anyone on the same network can decode. It also disables caching and enables debug output. The correct fix on production is always to install SSL and serve the site over HTTPS.

How do you confirm application passwords are fixed?

Run wp eval ‘var_dump( is_ssl() );’ to confirm SSL detection returns true, or wp eval ‘var_dump( wp_get_environment_type() );’ to confirm the environment is local. Then check the user profile page for the Application Passwords form. Finally, test authentication with curl using the –user flag against the /wp-json/wp/v2/users/me endpoint and confirm a 200 response.