WordPress Application Passwords: A Safer Way to Connect Your Site to Other Tools

WordPress site owners increasingly connect their websites to external tools: content schedulers, reporting dashboards, automation platforms, mobile apps, and AI assistants. These integrations can save time, but they also create a security question: how can another application access WordPress without being given the administrator's everyday password?

For supported WordPress installations, Application Passwords provide separate credentials for individual integrations. You can revoke one integration's credentials without changing your normal login password, making access easier to manage than sharing a single account password.

They are not a magic security shield. A credential can still be abused if it leaks, has excessive permissions, or is sent over an insecure connection. The goal is to give each integration only the access it needs and make that access easy to remove.

What Are WordPress Application Passwords?

Application Passwords are credentials intended for software that needs to authenticate to WordPress, particularly through its REST API. They are separate from the password you use to sign in to /wp-admin.

WordPress introduced the built-in feature in version 5.6. On a compatible site, a user can create a named Application Password from their profile. The name helps identify the connected tool later, while the credential itself is shown when created and should be stored securely.

For example, a site owner might create separate credentials for:

• A scheduled publishing service.
• A reporting script that reads post statistics.
• A trusted external editor or workflow tool.
• A development integration used for testing.

Separate credentials make it possible to revoke one connection without disrupting the others.

When Should You Use an Application Password?

Use one when an external program needs to authenticate to your WordPress site over HTTPS and the integration supports WordPress Application Passwords.

They are often a better choice than sharing your normal administrator password because they can be individually named and revoked. They are also preferable to installing a generic Basic Authentication plugin for production use. WordPress documentation describes Application Passwords as the built-in option for this kind of API access.

However, an Application Password is not a substitute for authorization. The account behind it still determines what the integration can do. If the connected account is an administrator, a compromised credential may have broad consequences.

Practical rule: create a dedicated WordPress user with the lowest role and capabilities that the integration actually needs. Do not automatically use an administrator account just because it is convenient.

How to Create a WordPress Application Password

The exact labels can vary slightly with the WordPress version, user permissions, and installed plugins.

1. Sign in to your WordPress dashboard using an account that is allowed to manage its own Application Passwords.
2. Open Users → Profile or edit the relevant user from Users → All Users.
3. Find the Application Passwords section.
4. Enter a clear name, such as Weekly Analytics Report or Editorial Automation.
5. Select Add New Application Password.
6. Copy the generated password immediately and save it in a password manager or secrets manager.

Treat the generated value like a password. Do not put it in a public repository, paste it into a public support thread, add it to a screenshot, or store it in a file that is served by your website.

If the Application Password section is missing, check that the WordPress installation supports the feature, that the connection uses HTTPS, and that a plugin, custom code, or hosting policy has not disabled it. Avoid changing security settings blindly on a live site.

How an Application Password Is Used

An external application typically sends the WordPress username and Application Password when making an authenticated request to the REST API over HTTPS. A command-line request can look like this:

curl --user "api-user:APPLICATION_PASSWORD" \ "https://example.com/wp-json/wp/v2/posts?context=edit" 

Replace the example domain, username, and credential with your own values. Do not copy a real Application Password into a tutorial or commit it to source control.

The context=edit parameter requests fields available in an editing context, so the request needs suitable permissions. For a read-only reporting tool, use an endpoint and account permissions that expose only the information it needs. Test with a non-production account first.

The request above is an example of the authentication pattern, not a recommendation to grant every integration access to edit posts. Endpoint permissions and the user's capabilities still apply.

Five Ways to Keep Application Passwords Secure

1. Require HTTPS

Application Passwords should be used over HTTPS. TLS protects credentials in transit between the client and your website. Check that the certificate is valid and that the integration uses the HTTPS URL, not an HTTP address.

HTTPS does not protect a credential stored insecurely on a laptop, in a source-code repository, or in application logs. Transport security is one layer, not the whole security plan.

2. Use a Separate, Least-Privilege Account

Create a dedicated user for the integration and assign only the role or capabilities it requires. A reporting tool that reads published content should not need the ability to install plugins, change site settings, or manage users.

WordPress roles are useful starting points, but custom integrations can introduce more granular permission requirements. Review what the integration actually calls and test its behavior with the intended account before deployment.

3. Give Each Integration Its Own Credential

Avoid reusing one Application Password across unrelated tools. Use a descriptive name for each credential so that you can identify it later.

If a service is discontinued or a device is lost, revoke the credential associated with that service rather than rotating credentials for every integration. This reduces disruption and makes incident response less chaotic, which is an unusually welcome outcome in website administration.

4. Store Secrets Outside Public Files and Repositories

For scripts, use environment variables or a secrets manager supported by your deployment environment. Restrict access to configuration files and never expose credentials in browser-side JavaScript, public HTML, screenshots, or logs.

If a credential has been committed to a repository or exposed in a message, assume it is compromised. Revoke it and issue a replacement after removing the exposure. Deleting the visible copy alone does not guarantee that the secret has disappeared from repository history, caches, or backups.

5. Revoke Credentials You No Longer Need

Return to the user's profile and review the Application Passwords list periodically. Remove credentials associated with old integrations, contractors, test scripts, or devices that are no longer in use.

If you suspect misuse, revoke the affected credential promptly, review WordPress and server logs where available, and investigate what the account could access. If the underlying WordPress user itself may be compromised, secure that account as well.

Application Passwords vs. Your Main WordPress Password

Application Passwords improve credential management, but they do not create a separate permission system. If the connected user has administrator privileges, the integration's effective access can still be powerful.

Common Problems and How to Troubleshoot Them

The Application Passwords section is missing

First, check your WordPress version and confirm you are editing the correct user profile. The feature may be disabled by a plugin, custom code, or hosting configuration. HTTPS and the site's authentication configuration can also matter.

Do not disable security controls or install an unmaintained authentication plugin just to make the section appear. Identify the cause and use the official WordPress documentation before changing production settings.

The API returns “401 Unauthorized”

A 401 response usually means the request did not authenticate successfully. Check that the username is correct, the Application Password was copied accurately, the credential has not been revoked, and the request reaches the intended site over HTTPS.

Also check whether a proxy, firewall, or security plugin is stripping or blocking the Authorization header. Do not paste the credential into a public debugging service to test it.

The API returns “403 Forbidden”

A 403 response can indicate that authentication succeeded but the user is not allowed to perform the requested action, although the exact cause depends on the endpoint and security configuration. Check the account's role and capabilities, the endpoint's permission requirements, and any security rules in front of WordPress.

Do not solve a permissions problem by switching the integration to an administrator account without understanding why the request was denied.

A REST API request fails even though the credential looks correct

Test the endpoint with a simple request, verify the site URL, and inspect the response body and server logs. Plugins, web application firewalls, reverse proxies, and hosting rules can affect REST API requests.

If WordPress itself reports a REST API error in Site Health, diagnose that underlying problem rather than repeatedly generating credentials. The guide to fixing “The REST API Encountered an Error” in Site Health explains how to follow the error details to the likely cause.

Connecting WordPress to Automation and AI Tools

Application Passwords can be useful when a supported automation tool or external application needs to work with WordPress content. Before connecting anything, verify which actions the tool will perform, which endpoints it calls, where it stores credentials, and whether it sends data to a third party.

For AI integrations in particular, distinguish between a tool that can read public content and one that can create posts, edit pages, or manage site settings. Start with read-only access when possible, then expand permissions only for a clear requirement. If you are exploring AI connections, The guide to connecting Claude or ChatGPT to WordPress with MCP provides useful context about the available approaches and their trade-offs.

Keep in mind that connecting an AI assistant or automation platform may involve data leaving your website. Review the provider's data handling terms and avoid granting access to private content unless it is genuinely necessary.

A Quick Pre-Launch Checklist

Before using an Application Password in production, confirm each item:

• The site uses a valid HTTPS connection.
• The credential belongs to a dedicated account with minimal permissions.
• The credential is unique to this integration and has a descriptive name.
• The secret is stored outside public files, browser code, and source control.
• The integration's requested endpoints and actions have been reviewed.
• Errors and logs do not reveal the credential.
• Someone knows how to revoke the credential if the integration is retired or compromised.

For broader WordPress hardening, review The overview of common WordPress security issues and their solutions. Application Passwords are one part of a safer site, alongside updates, backups, strong account security, and careful plugin selection.

Frequently Asked Questions

Are WordPress Application Passwords safe?

They can be a safer way to manage software access than sharing a user's main password, provided they are used over HTTPS, stored securely, limited to the necessary account permissions, and revoked when no longer needed. A leaked Application Password can still be abused.

Can I use an Application Password to log in to wp-admin?

Application Passwords are intended for application authentication, especially REST API access. They are not a replacement for the normal password used for a human login to the WordPress dashboard.

Can I revoke one Application Password without changing my main password?

Yes. You can revoke an individual Application Password from the user profile where it was created. This lets you disconnect one integration without changing the account's normal login password or other Application Passwords.

Do Application Passwords give an integration administrator access?

No, not by themselves. The permissions available to the integration are tied to the WordPress user and the requested endpoint. However, if you create the credential for an administrator account, the integration may have access to powerful actions. Use a dedicated, least-privilege account whenever possible.

Why does my Application Password request return a 401 or 403 error?

A 401 response generally points to an authentication problem, such as an incorrect username or credential. A 403 response often indicates that the authenticated user is not permitted to perform the action, though security rules can also affect the response. Check the endpoint, user capabilities, HTTPS connection, and server or security-plugin logs.

Official References

• WordPress REST API: Authentication — WordPress documentation for cookie authentication and Application Passwords.
• WordPress Common APIs Handbook: Security — WordPress guidance on validating, sanitizing, and escaping data.
• WordPress Common APIs Handbook: Sanitizing Data — guidance on handling untrusted input.
• OWASP API Security: Broken Object Level Authorization — why APIs must verify access to individual objects.