According to the Merriam-Webster dictionary, an "origin" is a
rise, beginning, or derivation from a source
. (1)
The concept of an "origin" on the web was first introduced by Netscape Navigator in version 2.02 in 1995; with the original intent to "automatically prevent scripts on one server from accessing properties of documents on a different server." (2) They didn't use the words "origin" but the heart of it was there. Since this time the Internet has evolved a lot and now there are 2 specific separation of origin policies, Same-Origin and Cross-Origin, that help build the trust relationship between a user and a resource.
SOP
The SOP (Same-Origin Policy) is a web browser security mechanism that prevents of JavaScript, and other scripting languages, from getting access to the DOM properties and methods. It is arguable the most important security concept within modern browsers, according to Google. (3)
According to RFC6454 section 3.5 "the same-origin policy uses URIs to designate trust relationships." (4) It does so by grouping URIs, by origin, as a representation of protection domains. These protection domains control which resources in a origin are granted authority to access objects and network resources within its own origin.
This policy is noticeably important for security because it is common browser behavior to include any cookies, including authentication session cookies, relevant to the other domain as part of the request when sending an HTTP request from one origin to another.
The RFC standard URL value that SOP follows is use an algorithm to match the protocol, hostname, and port of a request; though not all browsers care about the port.
The RFC standard says that
Two origins are "the same" if, and only if, they are identical.
In particular:
* If the two origins are scheme/host/port triples, the two
origins are the same if, and only if, they have identical
schemes, hosts, and ports.
* An origin that is a globally unique identifier cannot
be the same as an origin that is a scheme/host/port triple.
Two URIs are same-origin if their origins are the same.
NOTE: A URI is not necessarily same-origin with itself.
For example, a data URI [RFC2397] is not same-origin with
itself because data URIs do not use a server-based naming
authority and therefore have globally unique identifiers
as origins.
So, when the URI from above is compared with the URIs below you can see why they would not be considered "same-origin."
CORS
Cross-Origin Resource Sharing (CORS) is a mechanism that allows access to resources across origins. Implemented as an extension of the Same-Origin Policy, CORS enables servers to specify any other origins allowed to share resources with though a suite of HTTP headers that define any trusted origins and associated properties that are combined during the exchange between a Browsers and a resource across web origins. For example, if an API is used on http://example.org, http://hello-world.example can opt in using the mechanism of the Access-Control-Allow-Origin: http://example.org
as a response header, which would allow the resource to be fetched cross-origin from http://example.org. (8)
CORS has an "opt in" mechanism where user agents (Browsers) will, typically, isolate content retrieved from different origins, by default, to prevent malicious web site operators from interfering with the operations of benign web sites and to prevent leaking of data. (9)
Be Warned: This does NOT mean that CORS is security.
CORS != Security.
CORS is a way of easing up on the strict same-origin policy of resource sharing and NOT a mechanism to enforce general security or prevent against a variety of risky scenarios.
SOP and CORS Limitations and Importance
Implementing SOP and CORS doesn't mean your website is secure, but is an important security concept within modern browsers. (3)
SOP doesn't completely eliminate interaction between different origins and CORS is needed to allow a Browser and server to each evaluate whether any specific interaction may pose a threat and if not, allow it.
Furthermore, though reading between origins is usually blocked, this doesn't apply to HTML tags. This means a web page may freely embed cross-origin images, stylesheets, scripts, iframes, and/or videos and these resources still be accessed across origins through the associated HTML tag.
Lastly, though reading between origins is usually blocked this usually means you can still send a cross-origin requests but reading the response is prevented.
Resources:
- https://www.merriam-webster.com/dictionary/origin
- https://web.archive.org/web/20020808153106/http://wp.netscape.com:80/eng/mozilla/3.0/handbook/javascript/advtopic.htm#1009533
- https://code.google.com/archive/p/browsersec/wikis/Part2.wiki#Same-origin_policy
- https://tools.ietf.org/html/rfc6454
- https://portswigger.net/web-security/cors
- https://portswigger.net/web-security/cors/same-origin-policy
- https://fetch.spec.whatwg.org/
- https://www.w3.org/TR/2020/SPSD-cors-20200602/
- https://tools.ietf.org/html/rfc6454
- https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
Top comments (1)
What is the difference between CORS and CSP? Dua to make someone agree to what you say