Authenticating the WordPress REST API

When JavaScript running on your own WordPress pages calls the REST API, the browser already sends the logged-in session cookie. WordPress won't trust that alone for anything that changes state, because a cookie is sent on cross-site requests too — that's what CSRF is.

So it also requires a nonce: a short-lived token WordPress generates for the current user and action, sent in the X-WP-Nonce header. The block editor works exactly this way.

This is the right mechanism for admin screens, block editor extensions and front-end JavaScript on the same site. It's useless for anything else, because nothing outside the browser session has a valid cookie.

The common mistake is a nonce expiring. Nonces have a lifetime of around a day, so a page left open overnight will start getting 403s from a form that worked yesterday. Refresh the nonce, or handle the error by prompting a reload.

Built into core since WordPress 5.6, and the right default for server-to-server work. A user generates a named password from their profile screen, and it's sent with HTTP basic authentication.

What makes them good is revocability and granularity. Each integration gets its own credential with its own name, so you can see what exists and revoke one without affecting the others or changing the account password. If a credential leaks, you kill that one.

• Create one per integration, named so you know what it is six months later.
• Use a dedicated WordPress account for each integration, with the minimum role it needs — not your administrator account.
• They only work over HTTPS. Over plain HTTP, basic auth hands the credential to anyone on the network.
• Store them in environment variables or a secrets manager, never in a repository.
• Audit and rotate them periodically, and revoke immediately when an integration is decommissioned.

Common in headless setups where a separate frontend logs users in and then makes requests on their behalf. The frontend exchanges credentials for a signed token, then sends that token as a bearer credential on subsequent requests.

WordPress has no built-in JWT support, so this means a plugin, which means a dependency your authentication depends on. Check its maintenance status carefully before committing.

The implementation details matter more than the concept. Keep token lifetimes short and use refresh tokens rather than long-lived access tokens. Store tokens carefully on the client — localStorage is readable by any script on the page, which makes an XSS hole into a full account compromise. And make sure the plugin validates the signature properly and rejects tokens with the algorithm set to none, which is a classic JWT implementation flaw.

OAuth is for third-party applications acting on behalf of your users, where you don't want those users handing over their WordPress password. The user is redirected to your site, approves the application, and the application receives a token scoped to what was approved.

It's the right answer for a platform with many third-party integrations, and considerable over-engineering for a single internal integration. If you're connecting your own CRM to your own site, application passwords do the job with a fraction of the setup.

• JavaScript on your own WordPress pages → cookies and a nonce.
• A script, a cron job, or another server calling your site → application passwords.
• A headless frontend logging users in and acting as them → JWT, with short-lived tokens.
• Third-party applications acting for your users → OAuth.
• A public read-only endpoint → no authentication, deliberately, with nothing private in the response.

This is the distinction that catches people. Authentication establishes who is calling. Authorisation decides what they may do. A correctly authenticated request to a badly authorised endpoint is still a breach.

Every route needs a permission_callback that checks a capability with current_user_can, not a role. Role checks break on sites with custom roles, and they break when a plugin grants a capability to a role you didn't anticipate.

For endpoints acting on a specific object, check the capability against that object's ID. 'Can this user edit posts' is a different question from 'can this user edit this post', and only the second one is safe on a multi-author site.

On a site with no public API consumer, the sensible default is to require authentication for everything. The rest_authentication_errors filter lets you reject unauthenticated requests wholesale.

Do it carefully: the block editor and several core features call the API as the logged-in user, so a blanket rejection that doesn't exempt authenticated sessions breaks the admin. The pattern is to reject only requests with no authenticated user, not all requests.

Even on a site that stays public, restrict the users endpoint. By default it publishes author slugs, which is a ready-made username list for a credential-stuffing attempt.

• permission_callback set to __return_true to silence WordPress's warning, on an endpoint that returns private data.
• Checking that a user is logged in but not what they're allowed to do.
• Credentials in client-side JavaScript, where anyone can read them.
• Basic auth over HTTP rather than HTTPS.
• One shared application password used by four integrations, so revoking it breaks all of them.
• No rate limiting on authentication attempts, turning the API into a brute-force target.
• Verbose error messages that distinguish 'no such user' from 'wrong password', which confirms which accounts exist.

The test people skip is the one that matters: call every endpoint with no credentials at all and confirm it refuses. Then call it as a low-privilege user and confirm it still refuses what it should.

Do this for write endpoints specifically, and for any endpoint returning data that isn't public. It takes a few minutes with curl and it catches the class of mistake that causes actual incidents.