1

I want to make a HTTP GET request to a site in a different domain than the client site. The final objective is to display a dashboard in the client site for the data that in the source site. The server of the source site is not configured for CORS and therefore it's not possible to make a simple AJAX call using JavaScript.

So I have two options, either to set up a proxy or disable Same Origin Policy for the browser. This dashboard is to be displayed on a dedicated machine on a common display. Is it okay to disable Same Origin Request restriction for the browser since it's only used for this purpose? Thanks.

kovac
  • 4,945
  • 9
  • 47
  • 90
  • 3
    Depending on your needs, sure you can disable it. The main goal of CORS is to prevent XSS attacks. If you have a specific scenario where you're protected from XSS in other ways than go ahead and disable it on your browser. Just don't expect anyone else to disable those settings on _their_ browsers. – Dave Aug 30 '16 at 04:12
  • There are other options ~ http://stackoverflow.com/questions/15005500/loading-cross-domain-html-page-with-ajax – Phil Aug 30 '16 at 04:15
  • @Phil - Thanks for the resource, but using third party proxies or jsonp is not an option for me. – kovac Aug 30 '16 at 04:22
  • @dave - Thanks for mentioning XSS attacks. Here, with CORS we are protecting our site in case the external site (data source) is compromised right? So, if we can trust the security of the external site, we could disable CORS on our machine? – kovac Aug 30 '16 at 04:25
  • You've got it backwards. CORS prevents XSS attacks on the server being called _to_ (in your case the external server). If your site is compromised then they are at risk of being attacked through your site. Or if somebody decides to browse the internet on the browser you've updated, then a malicious ad (or something like that) could make AJAX requests on your behalf to any other site on the web. – Dave Aug 30 '16 at 05:26
  • @dave - okay, now I get it. Thank you! – kovac Aug 30 '16 at 05:29
  • @dave: CORS does not prevent anything. The Same Origin Policy does. CORS is a way to get around the SOP. Also, the SOP does not prevent XSS. It is just a mechanism that mitigates the possible effects of XSS. Also, the SOP protects your browser from leaking information, it does not directly protect servers, as requests can be sent anyways, just not read. – daniel f. Sep 02 '16 at 12:00
  • 1
    @danielf. yes you are correct. I misstated things a bit in my comments, but if you read my answer it is consistent with what you've pointed out. – Dave Sep 02 '16 at 15:05

2 Answers2

1

You have another option that you didn't mention: get the data from the external site server-side, and pass it to your own dashboard. This btw, is the preferred way.

daniel f.
  • 1,421
  • 1
  • 13
  • 24
  • Hi Daniel, yeah I know. The thing is my employer wants to display this dashboard on SharePoint Online and SharePoint online doesn't allow server side code. Indeed, I'd love to do what you suggested if it was viable. Thanks for the suggestion. – kovac Sep 02 '16 at 12:13
  • I see, makes sense. And the other site you are sending a request to doesn't even support jsonp-type of responses? – daniel f. Sep 02 '16 at 13:34
  • For the other site I need to send a token with the request to authenticate. jsonp doesn't allow headers right? Is there a way I can send a token with a jsonp? When I try the jsonp I got the unauthorised response but the cross origin error disappeared. So jsonp would've been a great idea if I could authenticate my request. – kovac Sep 02 '16 at 13:52
-1

You can disable it, but you need to understand the consequences. The main goal of the single-origin-policy is to help prevent XSS attacks. The SOP protects users from unknowingly having malicious AJAX making requests on their behalf.

With Cross-Origin-Resource-Sharing disabled, if malicious JavaScript is injected into a browser session, say through an ad network, then that JavaScript would be blocked from things like connecting to the user's online banking page.

When you indiscriminately bypass the SOP in a browser, then any browsing session can be attacked in this way. If you're on a secure network and can guarantee that your site isn't compromised, and the browser won't be used for other purposes, then-and-only-then you are guaranteed to be safe.

On the other hand, as soon as someone uses that browser to connect to an unknown site, you have opened an attack vector. It's probably best not to mess with that setting, but only you can determine what is best for your specific scenario.

Dave
  • 10,748
  • 3
  • 43
  • 54
  • "When you disable this setting, if your site is compromised and an attacker is able to inject some JavaScript into your page, then that malicious code can make AJAX calls on behalf of your users." – No. Really really not. If you disable the Same Origin Policy in the browser then the attacker can do that **even if your site is not compromised** and they can do it to any site, and it isn't for "your users" is if "for the user with the browser with the broken security policy". – Quentin Aug 30 '16 at 05:54
  • "The main goal of CORS is to prevent XSS attacks." — No, it isn't. The Same Origin Policy *sort of* does that. CORS *selectively* disables the same origin policy. – Quentin Aug 30 '16 at 05:56
  • @Quentin 1. I believe I made that clear in the third paragraph and what you've quoted isn't from the answer I posted. 2. I didn't say it completely prevents XSS but I'll edit to make that clearer – Dave Aug 30 '16 at 06:01
  • The second paragraph is a massive red herring. If a site is straight up vulnerable to XSS attacks then additional security flaws in the browser are irrelevant. – Quentin Aug 30 '16 at 06:05
  • The third paragraph doesn't make a whole lot of sense either. A site can be affected if the user is logged into it (or if it is a site that is private for another reason, such as being on a LAN, like a company intranet). It doesn't need the user to browse to it. – Quentin Aug 30 '16 at 06:07
  • After all these comments I read up on this. @dave - Can you please edit the answer to clarify these points before me accepting it. What I found out is that SOP is not intended to protect either the service or the site making request. It's there to protect the user. That is it doesn't prevent a XSS attack, but should that happen it protects the user by prohibiting the un-identified request accessing the web service as the user would do. – kovac Aug 30 '16 at 06:16
  • @Sadeep you're right. I tried to just copy and paste my comments which were a bit clearer in the context of the online conversation, but they made a poor answer. I've updated the answer and think it makes a lot more sense now. – Dave Aug 30 '16 at 19:16