BigBears Practical Tech

WordPress REST API 401 Behind Cloudflare: Prove Whether the Edge or Origin Rejected It

·

by

BigBears Editorial Team

The owned baseline

Tested on 2026-09-04 against blog.bigbears.me and its owned WordPress origin. The unauthenticated baseline used read-only GET requests. A second bounded control temporarily changed authentication state by creating one disposable WordPress Application Password, performed the same protected GET at origin and edge, and deleted the credential immediately afterward. No post, plugin, or Cloudflare WAF rule was changed.

Route Public edge Direct origin Evidence
/wp-json/wp/v2/users/me without credentials 401 401 Both bodies returned WordPress code rest_not_logged_in and data.status: 401

For this request, Cloudflare passed through the same WordPress authentication result. Changing a WAF rule would not fix the missing WordPress authentication.

Valid-auth control

A disposable WordPress Application Password was then created for an owned WordPress user solely for this test. The password value was never written to the evidence artifacts and was deleted immediately after the two requests.

Same protected route with valid authentication Status WordPress user Cloudflare marker
Direct origin 200 1 absent
Public edge 200 1 present

The valid request succeeded at both the origin and Cloudflare edge. Combined with the equivalent unauthenticated rest_not_logged_in responses, this proves the observed 401 came from missing WordPress authentication in this controlled case—not an edge-only Cloudflare rule. The test does not prove that every REST route, method, or security configuration behaves identically.

Fast split: edge or WordPress?

  1. Use one sanitized request and keep method, path, query, body, and authentication mode identical.
  2. Capture public-edge status, content-type, server, cf-ray presence, WWW-Authenticate, and the bounded JSON error code.
  3. Send the same request to the owned origin while preserving the production Host and HTTPS-forwarding context.
  4. If origin and edge return the same WordPress JSON code, debug WordPress authentication first.
  5. If origin succeeds but the edge fails, correlate the edge request with Cloudflare Security Events before touching rules.

WordPress-side checks

  • Cookie authentication needs a valid wp_rest nonce for manual requests from a logged-in WordPress session.
  • Remote HTTPS clients should normally use a WordPress Application Password rather than a development-only Basic Authentication plugin.
  • Confirm that the web server forwards the Authorization header before changing application code.
  • Separate authentication (401) from authorization/capability failures and nonce errors; do not treat every REST error as one problem.

Cloudflare-side checks

Do not disable the WAF globally. First require an edge-only differential: the same valid, sanitized request succeeds at origin and fails through Cloudflare. Then match the request to a Security Event and rule identifier. Adjust only the narrow path/method/rule condition needed, retest, and keep a rollback record.

Boundaries

This guide does not claim that Cloudflare caused the tested 401. It provides a controlled method for distinguishing WordPress authentication from an edge-only failure. If a valid sanitized request succeeds at origin but fails at the edge, correlate that request with Cloudflare Security Events before changing a narrow, reversible rule. Never publish credentials, authorization headers, cookies, nonces, private origin addresses, or full security-event payloads.

Official sources

Trending Posts

Recent Posts