WordPress REST API Authentication Test 🛡️

This page tests how your browser interacts with a WordPress REST API endpoint when you might be logged into WordPress in another tab. WordPress often uses cookies for authentication.

Your WordPress site should have the following HTTP headers for this test to be fully illustrative regarding credentials:

• Access-Control-Allow-Origin: * (or your specific domain)
• Access-Control-Allow-Credentials: true

---

Test 1: Attempting an Unauthenticated Request 🕵️‍♀️

This test uses fetch with credentials: 'omit'. This tells the browser not to send any cookies (like WordPress login cookies) with the request, even if Access-Control-Allow-Credentials: true is set on the server. You should not see your logged-in user details.

Run Test 1 (Credentials Omitted)

Test results will appear here.

---

Test 2: Attempting an Authenticated Request (If Logged In) 🍪

This test uses fetch with credentials: 'include'. If you are logged into WordPress in another tab on the same browser, and your WordPress site has Access-Control-Allow-Credentials: true, this request will send your authentication cookies. You should see your user details if you are logged in and the site is configured to allow credentialed cross-origin requests.

⚠️ If this shows your user details, it means JavaScript from other origins (if allowed by Access-Control-Allow-Origin) can make authenticated requests to your WordPress site if you are logged in. This is expected behavior with these settings but highlights the importance of controlling which origins are allowed.

Run Test 2 (Credentials Included)

Test results will appear here.

---

Explanation of Results 📝

• If Test 1 shows "User not logged in" or similar (e.g., status 401 or an empty user object): This is the desired outcome for an unauthenticated request. It means credentials: 'omit' is working as expected.
• If Test 2 shows your user details (e.g., your username, email): This means your browser sent your WordPress authentication cookie because of credentials: 'include' and the WordPress server's Access-Control-Allow-Credentials: true header. This demonstrates that JavaScript on an allowed origin can indeed make authenticated requests if you're logged in.
• If Test 2 shows "User not logged in" even if you are logged in:
  • Double-check you are logged into the WordPress site in another tab in the same browser.
  • Verify the WordPress URL is correct.
  • Ensure your WordPress site is actually sending Access-Control-Allow-Credentials: true for the API endpoint.
  • Check the browser's console (F12) for any CORS errors or other messages. The server might be rejecting the request for other reasons.
• Network Errors / CORS Errors: If you see network errors in the browser console, it likely means Access-Control-Allow-Origin is not set to '*' or to the origin of *this* test page (which might be `null` if run as a local file). For this test to fully work against your site, your WordPress site needs to allow requests from the origin serving this page.

Key Takeaway: To prevent inadvertent authenticated requests from JavaScript on other domains, you would typically avoid Access-Control-Allow-Credentials: true or be very restrictive with Access-Control-Allow-Origin. If you must use both, be aware that any script on an allowed origin can make requests as the logged-in user.

For unauthenticated requests from your own JavaScript (even on the same domain, but especially cross-origin), explicitly use credentials: 'omit' with fetch for clarity and to ensure no cookies are sent. WordPress REST API also often uses nonces for write operations to protect against CSRF attacks, which is a separate but related security measure.