How to Fix 401 Unauthorized in WordPress

A WordPress 401 Unauthorized or Authorization Required response means the request did not provide credentials that the responding layer accepts. The rejection may come from HTTP Basic Auth in the web server, WordPress REST API authentication, a security rule, or a CDN in front of the site. The right fix depends on identifying which layer produced the 401 before changing passwords or disabling protection.

Why This Happens

HTTP Basic Auth is protecting the request

Staging sites and sensitive directories are often protected with HTTP Basic Auth. Apache may use .htaccess and .htpasswd, while nginx usually references a password file from its server configuration. A successful challenge includes a WWW-Authenticate response header and waits for the client to retry with an Authorization header.

Protection sometimes remains enabled after a staging site becomes public, or a rule intended for /wp-admin/ applies to the entire virtual host. Background jobs, webhook senders, and REST clients do not automatically know those credentials, so they also receive a 401.

WordPress rejected REST API credentials

A request to /wp-json/wp/v2/... may reach WordPress but lack valid application authentication. Common examples include an expired or revoked Application Password, an invalid JWT handled by a plugin, or a cookie-authenticated request missing its WordPress REST nonce.

WordPress REST errors such as rest_not_logged_in or rest_forbidden can be surfaced as 401 responses depending on the endpoint and authentication path. A headless frontend, mobile client, or plugin may show only the status code while the JSON response contains the useful error code.

A hotlink or WAF rule matched

Referrer-based hotlink protection can reject images, fonts, or downloads when the Referer header is absent or does not match an allowed site. Although 403 is common for these rules, some configurations return 401. A web application firewall can do the same when a request matches an authentication or access-control rule.

Referrer checks are imperfect because clients may omit the header for privacy or policy reasons. A rule that assumes every legitimate request sends it may block valid visitors.

The CDN rejected the request

CDNs and reverse proxies can enforce edge authentication, signed URLs, or access policies before contacting the WordPress origin. To a visitor, that 401 looks like an application response. WordPress logs remain empty because the request never reached PHP.

Diagnosing the Responding Layer

Start with the exact failing URL and avoid testing only the homepage. An asset, REST route, and admin path can pass through different rules.

Inspect response headers and the response exchange:
```
curl -I https://example.com/protected-path
curl -v https://example.com/wp-json/wp/v2/posts
```
Look for WWW-Authenticate, CDN-specific tracing headers, a JSON REST error, redirects, and the reported server. Header names can suggest a layer, but they are not proof because proxies can add, remove, or preserve origin headers.
If you control the origin endpoint, compare the public response with a request sent directly to the origin while preserving the hostname:
```
curl -I --resolve example.com:443:192.0.2.10 https://example.com/protected-path
```
Replace the documentation address with the actual origin address. A public 401 paired with a successful origin response points toward the CDN or edge configuration. Protect the origin from general public access and run this test only from an authorized network.
For REST failures, request the endpoint in a way that preserves the response body:
```
curl -i https://example.com/wp-json/wp/v2/posts
```
Confirm whether a public endpoint also fails. Then reproduce the authenticated request using the same method as the application. Do not paste production credentials into shared terminals, logs, or tickets.
Correlate the request time with CDN, web-server, WAF, and WordPress logs. If the CDN records a rejection but the origin has no matching access entry, investigate the edge. If the web server logs a 401 without a PHP request, check Basic Auth or server rules. A WordPress REST JSON error points to the application authentication path.

Fixing Each Cause

Remove or narrow accidental Basic Auth

For Apache, locate the applicable configuration rather than assuming the nearest .htaccess file is the only source:

AuthType Basic
AuthName "Staging"
AuthUserFile /secure/path/.htpasswd
Require valid-user

Remove the block when protection is no longer required, or scope it to the intended environment or directory. In nginx, review auth_basic and auth_basic_user_file at the http, server, and location levels because child locations can inherit settings. Reload the server only after validating its configuration.

Repair REST API authentication

Confirm the endpoint's required capability and authentication scheme. For an Application Password, revoke the exposed or invalid credential and generate a replacement for the correct WordPress user. Update the client through its secret store, then test a low-risk endpoint before resuming writes.

For cookie authentication, send the REST nonce in the X-WP-Nonce header and refresh it when the session changes. For JWT or OAuth-style plugins, follow that plugin's documented issuer, signing, and expiry configuration. Disabling REST authentication checks globally may expose private data and is not a safe shortcut.

Correct hotlink and WAF rules

Inspect the matched rule and its scope. Allow the site's canonical hostnames and required third-party consumers, account for legitimate requests with no referrer, and exclude REST or admin paths from asset-only rules. Test both browser navigation and direct asset requests after the change.

Ongoing rule review can be included in WordPress maintenance, while an unfamiliar 401 can be investigated through WordPress support.

Adjust CDN or reverse-proxy access

Review edge authentication, signed-URL expiry, origin-shield, and path-matching rules. Correct the rule that owns the failing hostname and path rather than adding credentials inside WordPress. Purge configuration caches if the provider requires propagation, then compare edge and origin tests again.

Preventing Another 401

Document which layer owns authentication for every protected path. Keep staging protection separate from production configuration, rotate application credentials without logging them, and add a deployment check for public pages, REST endpoints, and critical assets. Monitor 401 counts by path and responding layer so a sudden change is actionable.

How Nova Handles This

Nova uses managed Traefik and WAF ingress in front of tenant-isolated Kubernetes namespaces, which helps separate edge rejections from WordPress application responses during diagnosis.

FAQ

Is a 401 the same as a 403?

No. A 401 generally means acceptable authentication is missing or failed, while a 403 means the server understood the identity or request but refuses access. Real systems sometimes use either code for security rules, so inspect the response and logs.

Does `WWW-Authenticate` prove WordPress sent the error?

No. The header indicates an authentication challenge, commonly from a web server or proxy. Compare edge, origin, and WordPress logs to identify where it was added.

Can clearing cookies fix a WordPress REST 401?

It may help if the failure comes from a stale logged-in session or nonce, but it will not repair an invalid Application Password or an edge rule. Reproduce the request and read the REST JSON error before resetting client state.

Should I disable the security plugin to test?

Prefer disabling or bypassing the specific rule in a controlled window. Turning off an entire security layer changes too many variables and may expose the site. If that is the only available test, take a backup and restrict access first.