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.
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 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."
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.
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.