Origin

Cross-origin access control depends on identifying where a request came from. The Origin request header provides the origin (scheme, host, and port), giving servers the information needed to enforce CORS policies.

Table of Contents

Usage

Browsers attach the Origin header to CORS-mode requests, WebSocket handshakes, and any request using a method other than GET or HEAD, while plain no-cors subresource loads like images and scripts travel without the header. The header identifies where the request originated, giving the server the information needed to enforce access control policies. WebSocket servers lean on the value especially hard, since the handshake is the one place a server distinguishes a page-initiated socket from any other client before accepting the upgrade.

The header appears in all CORS requests (including preflights), form submissions using POST, and requests initiated by the Fetch API or XMLHttpRequest when the request is cross-origin or uses a method other than GET or HEAD. The browser does not include the header in same-origin GET or HEAD requests, whether navigations or API calls.

Unlike the Referer header, Origin never includes the path or query string, making the value more privacy-preserving. The Sec-Fetch-Site header provides a complementary signal by classifying the request as same-origin, same-site, cross-site, or none.

Values

scheme://host:port

The full origin consisting of the protocol, hostname, and port. The port is omitted when the protocol uses a default port (80 for HTTP, 443 for HTTPS).

Origin: https://app.example.re

Origin: https://api.example.re:8443

null

Sent when the origin is privacy-sensitive or opaque. Sandboxed iframes, data: URLs, and redirects across origins produce a null value.

Origin: null

Server-side validation

Checking Origin on state-changing requests is a standing CSRF defense. The server compares the value against an allowlist of its own origins, rejects mismatches with 403, and decides a policy for absent headers, where rejecting suits browser-only endpoints and allowing suits APIs serving non-browser clients that never send the header. The check complements SameSite Cookies rather than replacing token-based CSRF protection, and one edge deserves attention: a no-referrer referrer policy turns Origin into null on non-CORS POST requests, so an allowlist check on such deployments rejects requests from the site's own pages.

Example

A cross-origin POST from a front-end application includes the Origin header so the server verifies the caller before returning a CORS-enabled response.

Request

POST /api/orders HTTP/1.1
Host: api.example.re
Origin: https://shop.example.re
Content-Type: application/json

Response

HTTP/1.1 201 Created
Access-Control-Allow-Origin: https://shop.example.re
Vary: Origin

A preflight OPTIONS request carries the origin alongside the intended method and headers.

Request

OPTIONS /api/orders HTTP/1.1
Host: api.example.re
Origin: https://shop.example.re
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type

Crawlers and Origin

Verified crawler probe

Probe data from verified crawler traffic (September 2026 snapshot) shows which bots send Origin when requesting pages. Yes marks the header on at least nine of ten sampled requests from the bot, Sometimes marks a smaller share, and No marks absence.

Crawler Sends Origin
Amazonbot No
Applebot No
Baiduspider No
Bingbot No
ClaudeBot No
DuckDuckBot No
GPTBot No
Googlebot No
Googlebot (smartphone) No
Googlebot-Image No
Meta-ExternalAgent No
Meta-WebIndexer No
OAI-SearchBot No
SeznamBot No
YandexBot No
YandexFavicons No

See also

Last updated: September 21, 2026