Application Passwords in WordPress: How to Audit and Secure API Access

What Are Application Passwords, and How Do They Differ from a Regular Password?

An Application Password is a separate credential created in a WordPress user's profile for a specific integration. For example, it may be used by a CRM, mobile application, automated publishing service, external backup system, or script that communicates with the REST API.

This key does not replace the user's primary password. If an Application Password is revoked, the user can still log in to the admin area with their regular password. However, the integration that used the revoked key will lose access.

The key does not grant more permissions than those available to the user to whom it belongs. An administrator's Application Password has administrator-level consequences, while an editor's key provides only the access allowed by the editor role and the specific WordPress capabilities.

When an Application Password is created, WordPress displays the full value only once. It should not be shared in plain text through chats, email, repositories, or configuration files accessible from the web.

• The user's primary password does not need to be shared with an external system.
• A separate key can be created for each integration with a clear, descriptive name.
• An individual key can be revoked without changing the primary password.
• If a key is compromised, the access available to the corresponding user is compromised as well.

What Risks Do Old or Unknown Keys Create?

The most common problem is that a key was created for a test or temporary service but was not deleted when the work ended. Another scenario is that an integration is no longer used while its access remains active for years. If the token has ended up in logs, backups, a repository, or a third-party service, it may be used without knowledge of the primary password.

The level of risk depends on the user's role. An unknown administrator key is especially dangerous: through the API, it may allow changes to content, users, settings, or installed components if the relevant actions are available through specific endpoints. An editor key is not harmless either: an attacker may modify content, upload media files, or perform other permitted actions.

Application Passwords are not a way to bypass WordPress permissions. However, they can provide persistent access that goes unnoticed, especially when the site owner does not monitor API requests or audit user accounts.

• Unknown keys whose names no one can explain.
• Keys created for services that have been removed or replaced.
• Keys belonging to former employees, contractors, or test accounts.
• Multiple keys for one integration without a clear reason.
• Keys that were stored in a public repository, chat, or configuration.

How to Audit Application Passwords

The review should cover all users who may have such keys, not only the primary administrator. Pay particular attention to administrators, editors, technical accounts, and users whose accounts are used for automated publishing.

In each user's profile, review the list of created Application Passwords. It usually shows the key name and creation date, but not the password secret itself. If the name does not explain the purpose of the access, contact the person responsible for the integration or check the service configuration.

Maintain a simple access register containing the integration name, user, creation date, responsible person, and date of the last review. This helps prevent keys from being left active after a project ends and enables a faster response to team changes.

• List all active integrations that connect to WordPress.
• Match each integration to a specific user and Application Password.
• Ask service owners whether the key is still being used.
• Delete keys with no confirmed purpose.
• After the audit, check error logs and the operation of automations.

What to Do If a Key May Have Leaked

Do not limit your response to renaming the key or changing the primary password. An Application Password that may have become known to unauthorized parties must be revoked in the user's profile, and a new one should be created only if necessary.

If the key belonged to a user who no longer works with the site, review that account, its roles, and other active sessions. If necessary, block or delete the user according to your internal procedure. Also check web server, WAF, or monitoring logs for suspicious API requests.

• Revoke the compromised key.
• Review the account's activity in the logs.
• Check for new users and changes to content or settings.
• Replace the key in the service if the integration must remain active.

How to Revoke or Replace an Application Password

Revocation is performed in the profile of the relevant WordPress user. Find the required key by name and delete it. After that, all requests authenticated with this key should stop working.

If the integration is still required, prepare a new key first, update it in the service's secure storage, and test the integration. Revoke the old key after the test succeeds—or immediately if a leak is suspected.

For automations, do not use an administrator account unless necessary. Create a separate user with the minimum required role and permissions. This reduces the impact of a compromise, although it does not replace key management or protection of the server itself.

Make sure the integration sends the Application Password over HTTPS in an authorization header rather than adding the secret to the URL. Do not record the key value in request logs or error messages.

• Use a separate key for each integration.
• Give keys clear names, such as “CRM production” or “Mobile app testing.”
• Store secrets in a secrets manager or protected environment variables.
• Do not hard-code keys in theme or plugin files or in a public repository.
• After changing a key, test not only a successful request but also automation error handling.

How to Disable Application Passwords If API Access Is Not Required

If the site has no integrations, mobile applications, automated publishing, or other workflows that use Application Passwords, the feature can be disabled. This reduces the number of available authentication methods, but dependencies should be checked before making the change.

For a permanent configuration, use a mu-plugin rather than a temporary snippet in the theme file. Code in a theme may disappear after the theme is updated or changed, whereas a mu-plugin loads independently of the active theme. Create a PHP file in WordPress's must-use plugins directory and add:

• Before disabling the feature, check CRMs, mobile applications, and automated publishing.
• Check whether any external service uses XML-RPC or the REST API.
• After the change, test forms, imports, synchronization, and background tasks.
• Document the reason for disabling the feature so another administrator does not enable it without checking dependencies.

<?php
/**
 * Disable Application Passwords for all users.
 */
add_filter( 'wp_is_application_passwords_supported', '__return_false' );

When Not to Disable the Feature Without Checking

Not every integration explicitly indicates that it uses Application Passwords. The site may exchange data with a CRM, mailing service, mobile application, or internal script through the REST API. After the feature is disabled, these processes may begin returning authentication errors.

If the feature must remain enabled, the safer approach is to inventory the keys, revoke unnecessary ones, limit the user's permissions, and control access to the server and secrets.

• Do not add the code to functions.php if it is intended to be a permanent security rule.
• Do not use disabling Application Passwords as a substitute for auditing users.
• Do not delete all keys without approval if the site depends on automations.

Common Mistakes When Working with Keys

The most common mistake is storing an Application Password in a repository together with code or sharing it in a team chat. Even after a message or commit is deleted, the secret may remain in history, caches, and backups. In this situation, the key must be revoked rather than simply removed from the current file.

Another mistake is using one key for multiple services. If it becomes invalid or is compromised, all integrations will stop at once, and identifying the source of the problem will be more difficult.

You should also not assume that changing the primary password automatically resolves the problem with all Application Passwords. Active keys must be reviewed and revoked separately according to WordPress policies and the site's specific configuration.

• Do not send the key in a URL or exposed request parameter.
• Do not store the secret in JavaScript delivered to the browser.
• Do not use an administrator where a separate user with limited permissions is sufficient.
• Do not leave test keys on a production site.
• Do not postpone an audit after a contractor or team member changes.