liveBook · Manning

Origin

As explained in Grokking Web Application Security

A web origin is the combination of a resource's protocol, domain, and port that determines its browser security boundary.

Origin is the browser’s security boundary for web resources. Two URLs share an origin only when their protocol, domain, and port all match; a different path does not matter. For example, https://www.example.com/profile matches https://www.example.com, but http://www.example.com, https://www.example.org, https://www.example.com:8080, and https://blog.example.com do not. section 2.4 section 2.4

URL

Same origin?

https://www.example.com/profile

Yes. The protocol, domain, and port match, even though the path is different.

http://www.example.com

No. The protocol differs.

https://www.example.org

No. The domain differs.

https://www.example.com:8080

No. The port differs.

https://blog.example.com

No. The subdomain differs.

Compare URLs against a single base URL to see why small-looking changes, including a port or subdomain, create a different origin. section 2.4

The same-origin policy stops JavaScript in one origin from interacting with tabs or windows at another origin. This prevents a malicious site from reading sensitive content in a banking site that remains open and logged in. Same-origin windows can communicate, which supports applications that open separate windows or tabs. section 2.4 section 2.4

Cross-origin behavior is deliberately uneven:

  • Writes, such as following a link to another site, are permitted. section 2.5
  • Embeds, such as images, can be permitted when content security policies allow them. section 2.5
  • JavaScript reads through XMLHttpRequest or Fetch are normally limited to the origin that loaded the page. section 2.5
  • A server can explicitly permit cross-origin reads with CORS response headers; allowing a specific trusted origin is tighter than Access-Control-Allow-Origin: *. section 2.5

A third-party service request

A page may need JavaScript to request data from a separately hosted help or chat service. The remote server must opt in through CORS for the browser to expose that response to the page’s JavaScript. When no cross-origin access is needed, omitting CORS headers is the safer default. section 2.5 section 2.5

Origin also isolates browser storage. localStorage and sessionStorage are separated by origin: pages at the same origin can use the same storage, while different websites cannot read it. localStorage persists data, whereas sessionStorage lasts until the page closes. section 2.9 section 2.9

How Grokking Web Application Security covers it

How deep it goes
Defines protocol-domain-port matching and applies it to windows, requests, CORS headers, and storage isolation.
Examples
Compares example URLs and uses Fetch, XMLHttpRequest, CORS headers, and a localStorage shopping cart.
What it assumes
Introduces origin through familiar URLs while assuming awareness of browser pages, JavaScript, and server responses.
What you can do after
Operate/configure cross-origin data access by recognizing origin mismatches and limiting CORS permissions to trusted origins.
How it connects
Connects the same-origin policy with CORS, Fetch, XMLHttpRequest, content security policy, localStorage, and sessionStorage.

Also explained in

Compare how 3 books explain origin →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Grokking Web Application Security. The section links point to the parts of the book it draws on.