WordPress Application Passwords: pros, risks, and a step-by-step guide to create one

If you run WordPress and you have never touched Application Passwords, you are missing one of the most useful tools the CMS has shipped since 2020 — but also a side door that 80% of admins have wide open without knowing it.

Let us break them down: what they do, when they save you, when they expose you, and how to create one without getting in trouble.

What they are and why they were invented

Until WordPress 5.6 (December 2020), if you wanted an external script or a tool like Make, Zapier, MainWP, or your own crawler to read WP data via REST API (the technical doorway through which external apps read and write WordPress data without going through the admin panel), you had two bad options:

1. Put your real admin password in the script → anyone with access to that code has your whole account
2. JWT auth plugins (another token system, more complex to set up) which add complexity + external dependency

WordPress core added Application Passwords: tokens generated by WordPress itself, 24 characters long, bound to a user, and individually revocable. External apps authenticate via HTTP Basic Auth (the simplest way to send user + key in every request) with username:token against /wp-json/.

It is the closest thing to a lightweight OAuth (OAuth is the industry standard where the app asks the user for specific permissions) without plugins. Official docs: WordPress.org · Application Passwords.

Real advantages

1. You do not expose your human password

The token is NOT your login password. If the script is compromised, you revoke that token and your password stays intact.

2. Granular revocation

List all active app passwords in your profile. Delete any one without affecting the rest. Much better than “change the global password” — which forces you to update 10 sites where you have it hardcoded.

3. Auditable: name + last-used date

Each token carries an identifying name you pick when creating it + WordPress records the last-used date. At a glance: “I created this 6 months ago for Make and it has not been used since March → out”.

4. Does not break your 2FA

If you run plugins like Wordfence 2FA or Two Factor, your human login stays protected. The token skips 2FA only on REST API — because 2FA is meant for humans, not automated integrations.

5. Works out of the box

Zero plugins, zero server config. You enable them in your profile and your REST endpoint is ready with proper auth.

6. Universal compatibility

Any HTTP client that supports Basic Auth can consume your API. That includes Make, Zapier, n8n, curl, Postman, Python requests, WordPress plugins that need to connect to another install (MainWP), etc.

Real disadvantages and risks

Now the other side — the one almost no tutorial tells you:

1. User-level permissions, not granular

An app password has exactly the same permissions as the user who creates it. If you create it under your admin account, that token can:

• Create/edit/delete any post
• Upload media
• Change users and roles
• Install plugins and themes (= execute code on your server)
• Access your profile information

There are no scopes like OAuth (fine-grained permissions such as “read-only on posts” or “delete comments only”). It is all or nothing.

2. /wp-json/users/me endpoint reveals usernames

Once you have an app password, GET /wp-json/wp/v2/users/me gives you the username. And if you know the username + the token, you have the account. Never push tokens to a public repo or paste them in logs without redacting.

3. /wp-json/users itself lists usernames without auth

By default WordPress exposes /wp-json/wp/v2/users without authentication → any bot can enumerate your usernames. That is phase one of a brute-force attack against Application Passwords.

4. They do not expire by default

Once you create a token, it lives forever until you revoke it. If you forget you have one active and the app/service where you used it shuts down, it becomes orphaned + attackable.

5. Brute-force attacks against /wp-json/

Tokens are random 24-char strings, sure — but attackers do not go letter by letter. They look for leaks on public GitHub, paste sites, dumps, and when they find one they try it directly. With no rate limit on /wp-json/, they try thousands per hour.

6. Vulnerable to man-in-the-middle without HTTPS

Basic Auth sends the token in every request, Base64-encoded but NOT encrypted (Base64 is a reversible encoding anyone can decode; it is not real encryption). Without HTTPS, any intermediary network (public WiFi, malicious ISP, misconfigured proxy) can capture it.

7. No alerts when something goes wrong

If your app password is stolen and attackers start making weird requests, WordPress core does not email you or show anything in the panel. You need an audit plugin (Wordfence, WP Activity Log) or to check server logs manually.

When YES

When NO

• As a shortcut “to not type my password 5 times” → for humans use a password manager + 2FA, not app passwords
• For third-party apps you do not audit → if the app shuts down or gets compromised, attackers have permanent access until you notice
• No HTTPS on the server → cancel before generating anything
• If your site does NOT need the REST API enabled → better disable /wp-json/ entirely (plugins like “Disable REST API” or WAF rules)
• As your ONLY security layer → always paired with rate limit + 2FA on login + WAF

How to create an Application Password (step by step)

This is what many people ask — the actual flow, no screenshot spam:

Step 1: Check they are enabled

Login → Users → Your Profile → scroll to the bottom. If you see the “Application Passwords” section, it is active. If you do NOT see it:

• WordPress < 5.6 → upgrade core
• A security plugin may have disabled them (Wordfence, iThemes Security) → enable the option in its settings
• Some managed installs (WP Engine, Kinsta) block them by default → contact support

Step 2: Give it an identifying name

In the “New Application Password Name” field put something you will recognize 6 months from now:

• ✅ Good: Make - shop posts sync - 2026-05
• ✅ Good: MainWP dashboard finca
• ❌ Bad: test, try, new

This name will help you identify which token to revoke the day you lose it or clean up.

Step 3: Click “Add New Application Password”

WordPress generates a 24-character token in format XXXX XXXX XXXX XXXX XXXX XXXX (spaces every 4 chars).

Step 4: Copy the token NOW — it appears only once

⚠️ Important: the full token appears only once on screen. If you close the tab without copying, you have to revoke it and generate another.

Copy it to your password manager (Bitwarden, 1Password, KeePass) with a clear label: WP App Password · mydomain.com · name you gave it.

If the receiving app asks for it in no-spaces format, the spaces are cosmetic. WordPress accepts both formats when authenticating.

Step 5: Configure the receiving app

In Make/Zapier/MainWP/your script:

• Base URL: https://yourdomain.com/wp-json/wp/v2/
• Auth type: HTTP Basic Auth
• Username: your WordPress login username (not email)
• Password: the token you just copied (with or without spaces)

If the app talks about “Application Password” or “REST API token”, it is the same thing.

Step 6: Verify with a test request

Before pushing to production, test:

curl -u "your_user:xxxx xxxx xxxx xxxx xxxx xxxx" \
  https://yourdomain.com/wp-json/wp/v2/users/me

If it returns JSON with your user info → it works. If it returns 401 Unauthorized → check username + token + that your hosting is not stripping Authorization headers (some do).

Step 7: Put a date on your calendar

Set a reminder 90 days out: “review WP app passwords for mydomain.com”. Revoke the ones not in use, refresh the ones that are.

How to harden Application Passwords

If you are going to use them seriously, minimums:

1. Create a dedicated user per integration, with the minimum role needed (Editor or Author, not Administrator). The token inherits the user’s permissions.
2. HTTPS mandatory — without it, do not use them
3. Rate limit on /wp-json/ via WAF (Web Application Firewall — smart filter that decides which requests to let through) — free Cloudflare, ModSecurity, or SeoNova WPO Toolkit. Without it, bots will hammer leaked tokens
4. Block /wp-json/wp/v2/users without auth to stop username enumeration. Cloudflare WAF rule or .htaccess
5. Audit plugin (Wordfence, WP Activity Log) for alerts on weird activity
6. Rotation every 90 days or when a service changes hands
7. Never hardcode in public repos — use .env + secret manager

Connection with crawl budget: bots probing leaked tokens hammer /wp-json/ with hundreds of requests per minute. That is part of the 49.6% bot traffic from the Imperva Bad Bot Report. Blocking them also protects your Google indexing.

Wrap

Application Passwords are a brutal automation tool for WordPress without compromising your human account. Used well, they let you connect Make, Zapier, MainWP, scripts, and any REST integration with zero friction.

Used badly — no HTTPS, no rate limiting, no rotation, no minimum role on the user — they are an admin-level side door that lives forever until your token gets stolen.

Follow the 7-step setup + the 7-point hardening, and you stay on the side that captures the upside without paying the cost.

If you want to leave your /wp-json/ protected against brute force + bots + scrapers without touching plugins, the SeoNova WPO Toolkit ships a module built for exactly this. Blocks malicious activity before it hits your PHP — and recovers crawl budget for Google and Bing along the way.

Want to try SeoNova when we launch? Join the waitlist — 50 % off the first 3 months for early signups.

— The SeoNova team