Summary

  • Browsers needed a unit of trust large enough for a website's pages to work together. The January 2009 Origin draft described a request header and a possible CSRF check; RFC 6454 in December 2011 set out the broader origin concept that browsers had developed in practice.
  • The origin is built from scheme, host and port. Two paths under that tuple share a browser security context, while a different scheme or port crosses the line. That bargain puts a site's own hosting decisions inside the security model.

A site with two doors

Imagine an application under /account and a page of contributed material under /uploads/story on the same HTTPS host. Their jobs could hardly be more different. One handles an account; the other displays someone else's work. The browser sees the same scheme, host and port. The path after the slash does not enter its origin comparison.

That is the surprisingly blunt line recorded in RFC 6454, published in December 2011. The RFC did not create the same-origin policy from scratch. It says the policy had grown largely through browser practice, then gives that practice a precise vocabulary. Pages from one origin can work together as an application. The browser can restrict interaction across origins. The scheme, host and port determine which side of that boundary a network URL occupies.

The authors considered the obvious alternative: treat every URL as its own protected room. That would make an application with many pages laboriously ask permission for routine cooperation. The origin is a compromise. It gathers a useful set of resources into one browser principal, then makes the operator answer for what it puts in that set.

The port counted; the path did not

The RFC's examples make the rule visible. A page on example.com over HTTP shares an origin with another path on the same host when port 80 is stated explicitly; that is HTTP's default port. A different port, a www host name, or a move from http to https changes it. The last distinction matters because a secure page should not inherit the browser trust of content that an attacker could alter on the unencrypted side of the same host.

The path is absent from that calculation. /account and /uploads/story can live under different server permissions and still share an origin in the browser. The server can deny an account request; the origin rule does not replace that check. But if untrusted material is served as active HTML under the application's origin, the browser may run its script with that origin's privileges. RFC 6454 makes this point in its discussion of media types and user-generated content. A site may keep the same URL structure on paper while handing a new author a seat inside the browser's trusted room.

The security unit is therefore also a publishing decision. An operator chooses the host and port for user material and chooses whether it is delivered as HTML or an inert media type. The browser cannot infer from a polite /uploads/ label that the file deserves fewer rights. It uses the boundary the URL and the response give it.

A draft began with the request's sender

The January 2009 Origin Internet-Draft approached the problem from a request arriving at a server. Its proposed header let a user agent describe the security context that started an HTTP request; the draft said a server could use that information to defend against cross-site request forgery. It was an Internet-Draft, a proposal rather than an adopted standard. Its origin calculation, comparison and serialization already formed the machinery behind the header.

RFC 6454 widened the frame. An Origin request header reports the origin associated with causing a request, while the origin concept also defines how the browser groups pages before any request is sent. An opaque origin has no ordinary scheme-host-port triple and serializes as null. The RFC also prescribes null for a request from a privacy-sensitive context. Those four letters are an intentional answer from the browser's model, not a hostname waiting to be resolved.

The later W3C CORS Recommendation used origin information when a resource decided which other sites could read a response. Its own text separated permission to read the response from authorization of a request's side effects. That later invitation is a separate story. The origin rule underneath it decides who counts as the same browser principal in the first place.

RFC 6454 made a rough bargain legible. It gave web applications enough shared space to function without treating every URL as a stranger. In return, a host, a port and a response type became decisions about who got to stand inside that space. The browser counted the port. The publisher had to remember all the paths.