HTML and CSS Reference
In-Depth Information
■
Since most serialized origins use port 80, which matches the default HTTP port,
the port is commonly omitted from the origin. A typical serialized origin looks like this:
Note
Figure
7-1
shows an example origin, containing a scheme, host, and port.
Figure 7-1.
Diagram of an origin
If any component of two origins differs, browsers treat those origins as completely
separate origins. Browsers can enforce consistent rules for communicating and sharing
data between origins. For instance, applications with different origins can communicate
using the
postMessage()
API, but they are able to scope their messages based on the
origins of the sender and receiver.
Origin replaces older, less standardized, and more complex rules, sometimes referred
to as the “same-domain policy.” The same-domain policy was not comprehensive: pages
could still hotlink images and embed iframes from any origin. This policy included rules
for the
referer
header, which in addition to being spelled incorrectly by the specification,
included URL paths and thereby leaked too much information. As a result, referers
were frequently hidden and could not be relied on for access control. For cross-domain
scripting, non-standard rules were enforced for pages with partially matching origins that
differed only by port or scheme. In short, the same-domain policy was a mess.
The origin model cleans up all the cross-domain rules for web applications. It
defines an origin as the trio (scheme, host, and port). If two URLs differ at all in one of
those three ways, they have different origins.
The origin model also makes it possible to host public and semi-public services.
For example, a server could allow several origins, allowing connections to exchange
data with applications all over the Web. A public service could even try allowing every
origin by default, blocking only those origins known to be problematic. As such, origin is
more flexible than older same-domain policies under which
all
non-similar origins were
assumed to be malicious and were blocked by default.
Mitigating Denial of Service
Origin allows the receiving party to reject connections that it does not want to handle.
Web servers can inspect the origin header of incoming requests and choose not to handle
connections from unknown or possibly malicious origins. This ability can be extremely
helpful in mitigating denial of service (DoS) attacks.
