Browser same origin policy workaround

Browser same origin policy is to disable the original document from a domain accessing other document from another domain (cross domain). This policy has been introduced to prevent certain kinds of cross scripting attacks such as hijacking the user to remote site, stealing the cookies and impersonating the victim, key stroke logging e.t.c. This policy is enforced in most modern browsers(IE enforced this from version 8).

There is exception to the policy and it allows dynamic loading of script documents from another domain.  Using this exception we can call services from another domain that can return the JSONP format results. JSONP supports “On-Demand-JavaScript” which is ‘Ability to add new java script to the existing code dynamically by calling a service’.  When a service claims that it can give the result in JSONP format means that it actually returns the java script  which contains function invocation with the service results as parameter to that JavaScript function. e.g. If we call the following twitter search URL in the java script http://search.twitter.com/search.json?callback=foo&q=twitter. The call will return the java script method invocation foo(‘JSONData’) where ‘JSONData’ is  the service results (Twitter search results in this case). We need to define a java script function named foo which takes a JSON format parameter and do the processing.

The other workarounds are

Flash Policy files(http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html)  – The Cross domain needs to have a configuration file (cross-domain.xml) which mentions whether to allow the cross domain traffic or not. When cross domain hosts this file then we can make any type of call (Web service, Json, Html e.t.c) to the cross domain. There are many free third party Add-ons to support this. The popular one is “flxhr”

IE8 XdomainRequest - http://msdn.microsoft.com/en-us/library/cc288060%28vs.85%29.aspx

JSONRequest ( http://www.json.org/JSONRequest.html ) - Server doesn’t need to support the JSONP format  – This is in proposal not yet adopted or implemented by any browser or forum .




About these ads

About Thiru

I'm a full stack developer and have held roles in engineering & product. Contact details Email : chandarmk@yahoo.com / thiru@mavistech.com www.linkedin.com/in/thirumk website: mavistech.com W
This entry was posted in Web Development. Bookmark the permalink.

4 Responses to Browser same origin policy workaround

  1. Getting fed up with this policy! says:

    This is the second use case I’ve been blocked on with the “same-origin policy”.
    The first was easy enough – I was just using an API for GET requests, so JSONp was a good fit.

    This time, however, I have an SSL webservice where credentials are parameters, not HTTP headers taken from cookies. The credential scope is owned by my script, so (unless the browser is majorly compromised) should not be open to XSS abuse as cookies are.

    It’s so frustrating. I don’t really want to be coding the [somewhat convoluted/bodgy feeling] iFrame solutions.

    I cannot enable CORS on the server, and this cannot be relied upon as you’re not going to “own”/have influence over 99% of API’s you want to use.

    My question is: why the hell can’t they just protect the f’ing cookies!

    Cookies should not be cross-domain.
    HTTP requests should.

    Why aren’t they just trying to enforce that and letting people get on with using multiple API’s in client-side applications within browsers (producing value for users and service providers)?

    (my guess is the browser vendors are serving the interests of their own revenue models or those of their donors/benefactors that rely on tracking cookies to gather behavioural data and generate targeted advertising; but maybe I’m just being cynical!)

    • Thiru says:

      I completely agree with the observation.

      XDocumentRequest (IE8 and IE9) follows some basic sense approach i.e. don’t send/share much cookies especially authentication cookies to the cross domain but XDocumentrequest is not universal (won’t work on all browsers and has some restrictions (http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx). When I was working on the cross domain issues I heard that W3C is working on a proposal on lines of XDocumentRequest i.e don’t share cookies to the cross domains I am not sure what is the recent development.

      Another way to solve the problem if none of workaround helped is to introduce a webservice on your domain which will in turn call the cross domain (calling the cross domain from your own domain) and return the result back to client. This involves cookie scrapping and cookie building and may be performance bottleneck if there are too many calls from the client. Some of the third party API has some throttling based on the ip address. e.g. Twitter won’t allow more than 45 calls(approx) in a hour window from the same ip.

      • Thiru says:

        Another possibility to explore is use of Flash/Silver Light/Java cod at the client side to make the cross domain calls which is more generous in enforcing the same origin policy.

  2. Pingback: How to: Ways to circumvent the same-origin policy | SevenNet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s