可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

I was always wondering what the purpose of the XHR cross domain restrictions is.

It seems the intention is to prevent maliciously injected Javascript from sending private data to the attacker. However, sending data to any domain is easily possible with an injected script or img tag (or any other external resource for that matter).

回答1:

If any arbitrary website could make an XHR call to your website, then the following could happen:

Innocent user Alice logs into your secure website and acquires a secure session cookie.
In another browser tab, Alice visits Bob's evil hacker website (which she thinks is just a Justin Bieber video)
Bob's page issues an XHR to your secure website. Without the cross-domain policy, the browser would issue the request to your website — including the secure session cookie — and retrieve the results. Those results could include anything available to Alice while she's logged in to your secure site.

As it is, even with the cross-domain policy, Bob's evil website can in fact POST an HTTP request to your server by posting a form. It won't be able to see the results, but if Bob is clever he may have discovered a URL in your site that allows some activity from a POST even if it's not from a form on one of your pages. That's called Cross-Site Request Forgery, and it's something the browser cannot protect you from.

回答2:

Same-site security policy is designed so that for an attacker to be able to inject malicious script into a web page one of the following is required:

The web page references script or image resources that reside outside the web page's domain, and the attacker can gain control of one of those external resources.
The attacker has access to the host web server of the web page
Or the attacker has control of a machine on the route between the web server and the browser client (for unsecured http connections)

If you build your web site to only reference resources on your own domain, and you don't do anything stupid like accept javascript (or SQL) embedded in the URL or use javascript eval() on user input text, you're in relatively good shape for data privacy on your web page.

If you link to script or image resources that reside on a different domain, the security of your web site is dependent upon the security of that external domain as well.

The best way to protect against #3 above (man in the middle attack) is to secure all requests to your server (for page, script, and images) using https protocol instead of http. The man in the middle cannot produce a valid crypto certificate for the target domain, so the browser can at least warn the user that something is fishy about the site.

The classic case for same-site security is wrapping a target web page in an iframe on a page hosted by the attacker's evil.com server. If the parent page URL and the iframe content URL are on the same domain, then they are allowed to talk to each other and see each other's internal data, variables, DOM, etc. If the domains are different, the same-domain security policy states that the browser should not allow the iframe to see any variables or DOM info of its parent, nor the parent to see the variables or DOM of the iframe interior. This is to prevent unintended or inappropriate exchange of data between the two domains.

If the same-domain security policy were missing, then it would be a very simple matter for an attacker to wrap your bank web site in an iframe, lead you with misdirection (links on false email sent to you) to log in via the wrapped site, and casually observe all your bank activity. From there, they can drain your accounts in a matter of seconds.

Note also that XHR was added to the browser environment as a third party extension initially, so the best course of action was to follow the existing browser security model for client requests. XHR follows the same rules as the browser uses for fetching html pages, script, and images. If XHR were designed into the HTML spec from the start instead of being tacked on later, things might have been different for XHR. See the HTML5 PostMessage spec as an example.