Same Origin Resoure Sharing
Created at 2017-12-14 Updated at 2024-04-17 - 7 min. read Category web development
Same origin resource sharring is a important concept in web. In this policy a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, host name, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page’s Document Object Model.
We can imply this policy by the following ways
- CORS
- JSONP
- Cross Document Sharring
- Document Domain Property
- WebSockets
CORS
Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources (e.g. image) on a web page to be requested from another domain outside the domain from which the first resource was served. Certain “cross-domain” requests,are forbidden by default by the same-origin security policy.
Now lets understand how CORS work?
The CORS standard describes new HTTP headers which provide browsers and servers a way to request remote URLs only when they have permission. Although some validation and authorization can be performed by the server, it is generally the browser’s responsibility to support these headers and honor the restrictions they impose.
Firstly a http header as HTTP OPTIONS request method is sent, and then, upon “approval” from the server. It clarrifies which all method are allowed and is there any authentication required or not. Which is followed by sending the actual request with the actual HTTP request method.
Below is the flowchart for the above
Let’s understand this with an example.
When a CORS-compatible browser attempts to make a cross-origin request.
It sends OPTION request with origin HTTP Header. When a page from http://www.juggernaut451.com attempts to access a user’s data in test.juggernaut451.com, the following request header would be sent to test.juggernaut451.com which would basically tell the server from where the request have been generated.
Origin: http://www.juggernaut451.comServer on test.juggernaut451.com could reply with one of the following option:
An Access-Control-Allow-Origin (ACAO) header in its response indicating which origin sites are allowed. For example:
Access-Control-Allow-Origin: http://www.example.comAn error page if the server does not allow the cross-origin request
An Access-Control-Allow-Origin (ACAO) header with a wildcard that allows all domains:
Access-Control-Allow-Origin: *A wildcard same-origin policy is appropriate when a page or API response is considered completely public content and it is intended to be accessible to everyone, including any code on any site.
JSONP
JSONP, which stands for JSON stands for JavaScript Object Notation with padding, is a way to get data from another domain that bypasses CORS (Cross Origin Resource Sharing) rules. Due to inherent insecurities, JSONP is being replaced by CORS.
How JSONP works?
First a request is make to server that is JSONP enabled. In this request you pass a special parameter that tells the server a little bit about your page. That way, the server is able to nicely wrap up its response in a way that your page can handle. For example if a server is JSON enable it would expects a parameter called “callback” to enable its JSONP capabilities. The request would look like
http://www.juggernaut451.com/sample.aspx?callback=mycallback
Without JSONP, this might return some basic JavaScript object, like so:
{ foo: 'bar' }
However, with JSONP, when the server receives the “callback” parameter, it wraps up the result a little differently, returning something like this:
mycallback({ foo: 'bar' });
As you can see, it will now invoke the method you specified. So, in your page, you define the callback function:
mycallback = function(data){
alert(data.foo);
};
And now, when the script is loaded, it’ll be evaluated, and your function will be executed. Voila, cross-domain requests!
It’s also worth noting the one major issue with JSONP: you lose a lot of control of the request. For example, there is no “nice” way to get proper failure codes back. As a result, you end up using timers to monitor the request, etc, which is always a bit suspect.
Cross Document Messaging
Another technique, cross-document messaging allows a script from one page to pass textual messages to a script on another page regardless of the script origins. Calling the postMessage() method on a Window object asynchronously fires an “onmessage” event in that window, triggering any user-defined event handlers. A script in one page still cannot directly access methods or variables in the other page, but they can communicate safely through this message-passing technique.
Document Domain Property
If two windows (or frames) contain scripts that set domain to the same value, the same-origin policy is relaxed for these two windows, and each window can interact with the other. For example, cooperating scripts in documents loaded from orders.example.com and catalog.example.com might set their document.domain properties to “example.com”, thereby making the documents appear to have the same origin and enabling each document to read properties of the other. This might not always work as the port stored in the internal representation can become marked as null. In other words, example.com port 80 will become example.com port null because we update document.domain. Port null might not be treated as 80 (depending on your browser) and hence might fail or succeed depending on your browser.
WebSockets
Modern browsers will permit a script to connect to a WebSocket address without applying the same-origin policy. However, they recognize when a WebSocket URI is used, and insert an Origin: header into the request that indicates the origin of the script requesting the connection. To ensure cross-site security, the WebSocket server must compare the header data against a whitelist of origins permitted to receive a reply.