Fast Decision Table: 401 vs 403 vs CORS

Start with the failed request shown in the browser Network tab. Do not decide based only on the console message. The console may describe what the browser blocked, while the Network tab reveals what the server actually returned.

What a 401 Unauthorized Error Really Means

Despite its name, a 401 response is best understood as an authentication failure. The protected endpoint expected valid credentials, but the credentials were missing, expired, malformed, revoked, sent in the wrong place, or rejected for another authentication reason.

Common causes of a 401 response

• The Authorization header is missing.
• The bearer token expired or was revoked.
• The request uses BearerTOKEN instead of Bearer TOKEN.
• The token was created for staging but sent to production.
• The API key is placed in the wrong header or query parameter.
• The browser did not send the login cookie.
• The cookie domain, path, SameSite, or Secure setting prevents delivery.
• A reverse proxy strips the Authorization header.
• The endpoint expects Basic authentication, but the client sends a bearer token.

Correct bearer-token fetch pattern:

const response = await fetch("https://api.example.com/v1/profile", {
  method: "GET",
  headers: {
    "Authorization": "Bearer YOUR_TOKEN",
    "Accept": "application/json"
  }
});

const data = await response.json();

if (!response.ok) {
  console.error(response.status, data);
}

If this request returns 401, inspect the actual outgoing header in the Network tab. Do not assume the code you wrote is the request the server received. Interceptors, proxies, environment variables, extensions, middleware, and redirects can change the real request.

What a 403 Forbidden Error Really Means

A 403 response means the server understood the request but refuses to process it. Authentication may already be valid. Repeating the same login or refreshing the same token will not fix a permission rule, blocked account, missing scope, or resource-ownership problem.

Common causes of a 403 response

• The user is signed in but does not have the required role.
• The token is valid but lacks a required OAuth scope.
• The user is attempting to edit another user’s resource.
• The endpoint is limited to administrators or paid accounts.
• A firewall, CDN, WAF, hosting provider, or security plugin blocks the request.
• The IP address, country, domain, or origin is not allowed.
• A CSRF token, WordPress nonce, or framework permission check failed.
• The account is suspended, disabled, unverified, or outside a permitted organization.

A useful 403 response might look like this:

HTTP/1.1 403 Forbidden
Content-Type: application/json

{
  "error": "forbidden",
  "code": "ADMIN_ROLE_REQUIRED",
  "message": "You do not have permission to access this resource.",
  "request_id": "req_7f93a1"
}

The status tells the client the broad failure category. The machine-readable code explains the application-specific reason. The request ID lets a support team find matching server logs without exposing internal details.

What a CORS Error Really Means

CORS stands for Cross-Origin Resource Sharing. It is a browser mechanism based on HTTP response headers. It allows a server to tell the browser which other origins may read its responses.

An origin includes the scheme, hostname, and port. These URLs are different origins:

http://localhost:3000
http://localhost:5173
https://example.com
https://api.example.com
http://example.com
https://example.com:8443

If your frontend runs at http://localhost:5173 and calls https://api.example.com, the browser treats the request as cross-origin. The API must return permission headers that match the browser request.

Example response headers:

Access-Control-Allow-Origin: http://localhost:5173
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type, Accept

CORS is why an API can work in Postman or terminal cURL but fail in browser JavaScript. Postman and cURL can test the raw HTTP endpoint. Browser JavaScript also has to satisfy the browser’s origin rules.

The hidden preflight request

For certain cross-origin requests, the browser sends an OPTIONS request before the real request. This is called a preflight request. It asks whether the origin, method, and headers are allowed.

OPTIONS /v1/projects HTTP/1.1
Origin: http://localhost:5173
Access-Control-Request-Method: POST
Access-Control-Request-Headers: authorization, content-type

A successful server response might be:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: http://localhost:5173
Access-Control-Allow-Methods: POST, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 600

If that OPTIONS request returns 401, 403, 404, 405, or a redirect, the browser may stop before sending the real POST. This is why backend logs sometimes show no POST even though the frontend reports that it tried to submit.

How CORS Can Hide a Real 401 or 403

The server can return a real authentication or permission error, but the browser may refuse to expose its response body because the required CORS headers are missing.

Imagine that the API sends:

HTTP/1.1 401 Unauthorized
Content-Type: application/json

{
  "code": "TOKEN_EXPIRED",
  "message": "Your access token has expired."
}

If the response does not include a valid Access-Control-Allow-Origin header for the frontend origin, JavaScript may not receive that useful JSON body. Your application may only see a generic fetch failure, while the console emphasizes CORS.

The Practical Debugging Order

The fastest approach is to debug the request in layers. This prevents you from rewriting authentication code when the browser is actually failing at preflight.

Practical Request Examples

Bearer token with fetch

async function loadProfile() {
  const response = await fetch("https://api.example.com/v1/profile", {
    method: "GET",
    headers: {
      "Authorization": "Bearer YOUR_TOKEN",
      "Accept": "application/json"
    }
  });

  const data = await response.json();

  if (response.status === 401) {
    console.error("Authentication failed:", data);
    return;
  }

  if (response.status === 403) {
    console.error("Permission denied:", data);
    return;
  }

  if (!response.ok) {
    console.error("Unexpected API error:", response.status, data);
    return;
  }

  console.log(data);
}

Cookie-based authentication

When an API uses a login cookie, fetch may need credentials: "include":

const response = await fetch("https://api.example.com/v1/account", {
  method: "GET",
  credentials: "include",
  headers: {
    "Accept": "application/json"
  }
});

The server also needs compatible credentialed CORS headers:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true

A credentialed cross-origin response should use the specific permitted origin rather than a wildcard. Cookie delivery can also depend on the cookie’s domain, path, SameSite setting, Secure setting, and browser privacy controls.

Equivalent cURL test

curl -i "https://api.example.com/v1/profile" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Accept: application/json"

If cURL succeeds while browser fetch fails, compare browser-specific factors: CORS, OPTIONS preflight, cookies, HTTPS, redirects, and the frontend origin. If both fail with 401, the credential itself is probably the better starting point. If both fail with 403, inspect permissions or server policy.

Common Fixes That Do Not Solve the Real Problem

WordPress and Custom HTML Note

JavaScript inside a WordPress Custom HTML block runs in the visitor’s browser, so normal browser CORS rules apply. A request may work from PHP on the server but fail from the same WordPress page when called with fetch.

Use browser JavaScript for public APIs that explicitly allow your site’s origin. Use server-side WordPress requests for private API credentials and services that do not support direct browser access.

$response = wp_remote_get(
  'https://api.example.com/v1/profile',
  array(
    'headers' => array(
      'Authorization' => 'Bearer SERVER_SIDE_TOKEN',
      'Accept' => 'application/json',
    ),
    'timeout' => 20,
  )
);

Copyable 401, 403, and CORS Debugging Note

API authentication and CORS debugging note

Frontend origin:
Example: http://localhost:5173

API URL:
Example: https://api.example.com/v1/projects

Method:
GET / POST / PUT / PATCH / DELETE

Where it works:
Postman:
cURL:
Backend/server:
Browser:

Browser Network tab:
Is there an OPTIONS request?
OPTIONS status:
Real request status:
Was the real request sent?
Redirect present?

Authentication:
Bearer token / API key / cookie / Basic auth / OAuth / none

Authorization header present:
Cookie present:
Token expired:
Correct environment:
Required user role:
Required scope:
Resource owner:

CORS response headers:
Access-Control-Allow-Origin:
Access-Control-Allow-Methods:
Access-Control-Allow-Headers:
Access-Control-Allow-Credentials:

Exact browser error:
Paste the error without private credentials.

Server logs:
Request ID:
Timestamp:
Middleware or rule that rejected the request:

Likely category:
401 authentication
403 permission
CORS preflight
CORS response header
Cookie or credentials
Proxy, WAF, or hosting policy

Related CodeZips Tools

Technical References

• MDN Web Docs: 401 Unauthorized
• MDN Web Docs: 403 Forbidden
• MDN Web Docs: Cross-Origin Resource Sharing
• MDN Web Docs: Preflight Request
• MDN Web Docs: Access-Control-Allow-Origin
• MDN Web Docs: Access-Control-Allow-Headers
• MDN Web Docs: Access-Control-Allow-Credentials