If the origin of the request and target of the request do not match then it is a cross origin request . In other words if a web application running under one domain tries to access resources in another domain then it is called a cross origin request.
- For the purposes of matching only domain, scheme and port are considered.
- Subdomain is considered a different domain.
- Let us say user types http://example.com/page1 on browser addressbar.
- The origin of any request (script/non script eg a click on link) from this tab will be (scheme=https, host=thirdparty.com , port=80)
- The following requests would be examples of cross origin requests
- If the user clicks on link or makes a script request to http://sudomain.example.com (doamin does not match ,subdomain is considered a different domain)
- If the user clicks on link or makes a script request to http://anothersite.com (domain does not match)
- If the user clicks on link or makes a script request to http://example.com:8080 (port is not matching)
- If the user clicks on link or makes a script request to https://example.com (scheme is not matching)
- The following requests would be examples of same origin requests
- If the user clicks on link like http://example.com/page2
- If there is nothing in address bar (initial navigation by user ) or if the user types on the address bar then it will not be cross origin request.
- In case of redirect same rules apply (the request before and after redirection are normal http requests).
- For security reasons, the browser applies same origin policy to scripts. ie cross origin script requests are blocked. (cross orgin links etc are not forbidden) hence for cross origin script requests to work, CORS(cross origin resource sharing) header origin has to be part of request and this origin must be in the whitelist of destination. Read more about CORS https://clarifyforme.com/posts/5106719612993536/what-is-cors
- In case of spa the origin will the domain from where the spa's javascript was downloaded.
- Hybrid Apps running in Capacitor have capacitor://localhost (iOS) or http://localhost (Android) as their origin.
- If example.com loads an iframe with src="icicibank.com" and a navigation is done within iframe to icicbank.com, the request would still be considered cross origin as this is cross site iframe.
- Inherited origins :
- about:blank is often used as a URL of new, empty popup windows into which the parent script writes content (e.g. via the Window.open() mechanism). If this popup also contains JavaScript, that script would inherit the same origin as the script that created it.
- Note that data: URLs get a new, empty, security context. (requests will not be cross orgin)
- Cross origin access can be
- embedding
- JavaScript with script tag
- CSS
- Images displayed by img tag.
- Media played by video and audio tag
- Anything embedded by iframe tag.
- If windows share the same origin (host, port, protocol), then windows can do whatever they want with each other. otherwise, if it comes from another origin, then we can’t access the content of that window: variables, document, anything. The only exception is location: we can change it (thus redirecting the user). But we cannot read location (so we can’t see where the user is now, no information leak). Also messages can be posted.
- Also typically requests made from cross-site iframe will typically go without samesite=strict cookies . If a.com page loads icicibank.com in an iframe (the parent page origin and iframe origin do not match) and from iframe requests are made to icicibank.com , the requests will go without icicbank.com cookies which have samestie attribute strict. Also the response will be considered third party cookies. Note that if icicibank.com page was loading another icicbank.com page in iframe this issue would not be there.
- writes
- links
- forms
- redirects
- cross origin http requests from scripts.
- embedding
- The cookies sent as response to cross origin request will be considered third party cookies by browser.
- In response to cross origin javascript request, normal third party cookie policies are applicable, if a script loaded from a.com makes xhr request to b.com and if third party cookies are disabled in browser settings , then third party cookie will not be set (although note that error will not be thrown).
- SameSite cookie attribute can be used to control if cookies will go in cross origin requests.
- SameSite affects both first party and third party cookies.
- If the third party cookies are blocked in browser settings then they will not go even if SameSite=none.
- Firstparty/thirdparty cookies will go cross origin script requests if SameSite=none.
- A page may change its own origin, with some limitations.A script can set the value of document.domain to its current domain or a superdomain of its current domain. If set to a superdomain of the current domain, the shorter superdomain is used for same-origin checks.
- A script from the document at http://store.company.com/dir/other.html can set document.domain = "company.com"; After this requests made to compnay.com will pass the same origin check. Hence a subdomain can make xhr reqeuests to domain by simply modifying document.domain.
.