6 ms·

It's because that can break the site due to the browser's sandbox permissions model. Scripts are only allowed to make ajax calls to their origin servers. Also,

by asaph 8y ago

It's because that can break the site due to the browser's sandbox permissions model. Scripts are only allowed to make ajax calls to their origin servers. Also, serving a 3rd party script from the 1st party's domain gives the 3rd party permission to make ajax calls to the 1st party domain, which may open up security holes.

jszymborski 8y ago
You are totally right, but I'm wondering if we shouldn't change this practice. I'm starting to think if you're making a call to an external service, it should be proxied through your network. It'd increase bandwidth/latency, but you can be assured that the network calls your page are making are hitting the correct 3rd parties, and even inspect to see that the payloads are "correct". Edit: Surely, this at the very least should be the case for payment pages and banking websites.
- asaph 8y ago
  > ... but you can be assured that the network calls your page are making are hitting the correct 3rd parties ... The browser's sandbox security model already does this for us with the same origin policy. > ... and even inspect to see that the payloads are "correct". This is what SRI already does for us.
  - jszymborski 8y ago
    To the second point, I was thinking of checking what came over the wire after AJAX calls from 3rd party JS (which may or may not have been loaded with SRI). I'll have to concede the first point... I was thinking that you can whitelist entire URLs to be fetched as opposed to domains, but on second thought, I don't think that'd be a meaningful change. Thanks, this has made me think a lot more on this, however :)
euroclydon 8y ago
What? You must be talking about some opt-in sandboxing. What about the millions of sites that load jQuery from a CDN and then use $.ajax() to make requests to their home domain?
- deleted 8y ago
  [deleted]
paraditedc 8y ago
> Also, serving a 3rd party script from the 1st party's domain gives the 3rd party permission to make ajax calls to the 1st party domain, which may open up security holes. What do you mean? The 3rd script served from 3rd party domain will still execute under 1st party domain in the client's browser and that's the origin that the server sees. It doesn't prevent the scripts from calling 1st party server.
- asaph 8y ago
  If a 3rd party's script loaded from the 3rd party domain initiates any execution on its own (without being invoked by script on the 1st party's site), it won't have permissions to make calls to the 1st party's domain. Moving the 3rd party script to the 1st party domain opens this up. Update: Given the responses, I'm starting to think I might be incorrect on this point. I'll admit, I'm working from memory here. I'll have to go back and validate this.
  - woogley 8y ago
    I have never heard of this. Can you share a link that goes into detail about this behavior? I don't immediately see anything on MDN's same-origin page talking about it
    - benmmurphy 8y ago
      I'm 99% sure this is not a thing and if it was it would be incredibly broken and not secure and most non-trivial pages relying on it for security would be vulnerable to the third party script. Anyway. This can easily be proved one way or another. `Here is an example that shows a third party script accessing a first party domain. There is no CORs as far as I can see: https://jsfiddle.net/aopmtn46/ https://jsfiddle.net/aopmtn46/ If you open the console you will see "STATUS 404" which is not possible if same origin on third party scripts is enforced.
      - woogley 8y ago
        thank you for this test!

by asaph 8y ago

jszymborski 8y ago

You are totally right, but I'm wondering if we shouldn't change this practice. I'm starting to think if you're making a call to an external service, it should be proxied through your network. It'd increase bandwidth/latency, but you can be assured that the network calls your page are making are hitting the correct 3rd parties, and even inspect to see that the payloads are "correct". Edit: Surely, this at the very least should be the case for payment pages and banking websites.

asaph 8y ago
> ... but you can be assured that the network calls your page are making are hitting the correct 3rd parties ... The browser's sandbox security model already does this for us with the same origin policy. > ... and even inspect to see that the payloads are "correct". This is what SRI already does for us.
- jszymborski 8y ago
  To the second point, I was thinking of checking what came over the wire after AJAX calls from 3rd party JS (which may or may not have been loaded with SRI). I'll have to concede the first point... I was thinking that you can whitelist entire URLs to be fetched as opposed to domains, but on second thought, I don't think that'd be a meaningful change. Thanks, this has made me think a lot more on this, however :)

euroclydon 8y ago

What? You must be talking about some opt-in sandboxing. What about the millions of sites that load jQuery from a CDN and then use $.ajax() to make requests to their home domain?

deleted 8y ago
[deleted]

paraditedc 8y ago

> Also, serving a 3rd party script from the 1st party's domain gives the 3rd party permission to make ajax calls to the 1st party domain, which may open up security holes. What do you mean? The 3rd script served from 3rd party domain will still execute under 1st party domain in the client's browser and that's the origin that the server sees. It doesn't prevent the scripts from calling 1st party server.

asaph 8y ago
If a 3rd party's script loaded from the 3rd party domain initiates any execution on its own (without being invoked by script on the 1st party's site), it won't have permissions to make calls to the 1st party's domain. Moving the 3rd party script to the 1st party domain opens this up. Update: Given the responses, I'm starting to think I might be incorrect on this point. I'll admit, I'm working from memory here. I'll have to go back and validate this.
- woogley 8y ago
  I have never heard of this. Can you share a link that goes into detail about this behavior? I don't immediately see anything on MDN's same-origin page talking about it
  - benmmurphy 8y ago
    I'm 99% sure this is not a thing and if it was it would be incredibly broken and not secure and most non-trivial pages relying on it for security would be vulnerable to the third party script. Anyway. This can easily be proved one way or another. `Here is an example that shows a third party script accessing a first party domain. There is no CORs as far as I can see: https://jsfiddle.net/aopmtn46/ https://jsfiddle.net/aopmtn46/ If you open the console you will see "STATUS 404" which is not possible if same origin on third party scripts is enforced.
    - woogley 8y ago
      thank you for this test!