0

I'm extremely confused by this. When I started out in web development years ago, I remember running into the SOP blocking my requests.

Yet somewhere along the way since then I forgot about it and haven't run into it in years. I know it still exists, and yet I can do $.ajax or any other such variant without the request failing. My company's pages make dozens of requests to 3rd-party services through multiple frameworks with no issue.

What's the deal? Is it just that modern web frameworks and libraries know how to work around it, and take care of it for me? Just maybe since I haven't written out an XMLHttpRequest by hand in years I don't run into it anymore? Is there some option to the XMLHttpRequest, like origin, that solves this or something?

temporary_user_name
  • 35,956
  • 47
  • 141
  • 220
  • https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy try looking at that – Binvention Feb 13 '16 at 20:02
  • SOP never did block requests. It did (and does) block access to the response. – Bergi Feb 13 '16 at 20:02
  • You're looking for [CORS](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) – Bergi Feb 13 '16 at 20:04
  • I love getting downvoted without comments explaining where my question is lacking. How is this not an applicable, relevant, and valid question that's useful to others? – temporary_user_name Feb 13 '16 at 20:08
  • [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS) is the modern method for a server to allow cross origin access. Before that, a server-side work around was JSONP. If you are routinely using cross origin Ajax calls, then it must be to servers that are explicitly allowing such access via CORS. To be clear here, CORS is something that the server enables and a browser pays attention to. It is not something you do from your own client-side Javascript. – jfriend00 Feb 13 '16 at 20:13
  • 2
    A good reason for downvotes (though I didn't downvote myself) is that you're asking us what the deal is in your corporate web pages, but you offer ZERO technical information on the code, web sites, etc... that your corporate web site is using so there is NO way to actual answer your question specifically other than guessing. That's not a good question and probably deserves to be closed for that reason. – jfriend00 Feb 13 '16 at 20:15
  • while @jfriend00 was most probably correct, the asked question interested me too, and the accepted answer totally addressed what I was looking (GET requests does not trigger SOP). – Nurbol Alpysbayev May 28 '18 at 11:05
  • 1
    @NurbolAlpysbayev - Well, the accepted answer here happens to be wrong. The first paragraph is simply wrong. The Same Origin Policy does apply to GET calls made from Javascript, in fact it applies to all calls of any kind from Javascript. This isn't about whether it's a GET or not. It's about where the request comes from. HTML tags that cause GET requests like script tags and image tags and others are exempted from the same origin protections. – jfriend00 May 28 '18 at 15:49

1 Answers1

0

The basic rule

Same Origin Policy applies on any HTTP call made from the page to a domain different that the webpage's domain (including sub domain) other than for a GET call.

This means that if you add a script tag to the page, load an image or perform any kind of HTTP call which uses the GET method - then you have no problem. If, on the other hand, you try to use another method, such as POST, PUT, DELETE etc., to another domain then the browser will block the call and throw an error.

Ways around this

There are, though, several ways where you can get around this.

The first is to use a GET call, but have the other side interpret the call as something else. A great example of this is a technique called JSONP, which is where we add a script tag to the page (which is a GET call) and the server responding to the GET call doesn't return just a regular JS script, but rather it returns a "uniquely tailored" response, which references the code on the originating page to tell it that it has a suitable response.

There are several patterns for achieving this, the most common is the one build into jQuery, which is where the GET call adds a query parameter with a function name, and the returned script calls that function on the global scope. jQuery listened for that call and responds accordingly. To learn more go to this answer: Confused on how a JSONP request works

The wild card

The new way around this problem, which is a much cleaner solution than JSONp is something called CORS, which is a sort of contract between the browser and the web server. Essentially what a browser will do (assuming it supports CORS, older browsers do not) is, instead of blocking a "non GET" call entirely, the browser will first perform an OPTIONS call to the web server. The webserver will take a look at the request and decide what "options" (AKA methods) this client has for communicating with it. The default is, obviously, only one option: a GET call, but you can setup your webserver to support other options such as PUT, DELETE etc. To learn more about CORS look at https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Community
  • 1
  • 1
Che Kofif
  • 831
  • 1
  • 8
  • 22
  • Seems that both GET, POST cross-origin requests are allowed. You have to use CSRF token in order to avoid CSRF attacks, that can happen with POST requests. https://developer.mozilla.org/ru/docs/Web/Security/Same-origin_policy#Cross-origin_network_access – Nurbol Alpysbayev May 28 '18 at 11:22
  • 6
    This answer is simply not correct. The Same Origin Policy applies to any GET call to a different domain made from Javascript (e.g. an Ajax call to a different domain). For backward's compatibility and other reasons, script tags, image tags and other HTML tags (which only do GET calls) do not implement any CORs protection at all. But Ajax calls ARE subject to CORs regardless of whether it's a GET, PUT, POST, etc... So, this isn't about whether it's a GET or not, it's about what caused the request. In addition, some POST requests (like form submissions) are not subject to CORS either. – jfriend00 May 28 '18 at 15:48
  • I realised I just finally have understood how SOP works, thanks to your answer. Mozilla documentation was not so clear about that. – Nurbol Alpysbayev May 29 '18 at 10:48