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?

> 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.

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.

I very strongly doubt this is part of the browsers same origin model. Basically, this is only secure under the assumption that the third party script can't trick the first party script into invoking it by modifying its state since the third party script and the first party script both share the same global namespace.

Lets see how this is broken when jquery is running as a first party script.

    1. third party script calls $(document).on("..", function() {})
    2. event executes which causes jquery to invoke a function in the third party script
    3. third party script can now make a request to the 1st party origin bypassing the 'sandbox'

ok.. so maybe the browser tries to 'secure' against this attack by marking event listeners as either having a 'good' stack or a 'bad' stack. in this case when the third party script does $(document).on() it would be identified as 'bad' stack and couldn't then make the http request because the browser would see <bad stack> at the start of the event chain.

but this can still be worked around:

    1. third party script calls $(document).on("event", ".selector", function() {}) after 1st party script had already set a listener on document (not an abnormal thing)

    2. event happens and now it is run with 'good' stack because jquery uses a shared event handler and the event handler was originally registered with 'good' stack by the first party script. (the bad script doesn't even have to use the 'live' style. i suspect jquery shares event handlers for the same element so they would just need to try to add an event handler to an element that already has a jquery event handler)

there can be no security between scripts that share the same global state.

I don't think this is true. I just tried to replicate it with 2 different hostsnames pointing to 127.0.0.1 in my /etc/hosts. js loaded from origin2.foo on a page with an origin of origin1.foo can XHR things from origin1.foo, but not from origin2.foo.

Interestingly, MDN leads the article on same-origin policy with this sentence:

The same-origin policy is a critical security mechanism that restricts how a document or script loaded from one origin can interact with a resource from another origin.

This seems to support the way that OP described how SOP works.

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

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/

If you open the console you will see "STATUS 404" which is not possible if same origin on third party scripts is enforced.

thank you for this test!

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.

> ... 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.

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 :)