Access-Control-Allow-Origin标头是浏览器端还是服务器端安全机制？

Question

我们正在尝试保护我们的公众面向来自外部用户/域的JSON ASMX IIS服务页面。似乎将Access-Control-Allow-Origin标头设置到我们的特定域应该有助于阻止来自其他域的请求。是服务器实现此安全性还是浏览器？我在想是否可以绕过基于浏览器的安全性。

Answer 1

Access-Control-Allow-Origin是发送到浏览器的HTTP标头，表示某些来源可以访问所请求网站的内容。

  

origin参数指定可以访问资源的URI。   浏览器必须强制执行此操作。

所以，是的，它是客户端的。此技术旨在保护用户，但不保护服务器。服务器实际上只是发送此标头而不检查请求的来源 但是，只要用户使用任何现代浏览器，它就应该是绝对安全的。所有现代浏览器保证遵守CORS规则。

那么，CORS会保护您的用户免受不必要的跨域请求吗？是的。
malefactor是否有可能向您的域提出跨域请求？当然是。看起来对你的情况来说它不起作用。

Answer 2

Access-Control-Allow-Origin是CORS（跨源资源共享）标头。

当站点A尝试从站点B获取内容时，站点B可以发送Access-Control-Allow-Origin响应标头，告诉浏览器该页面的内容可以访问某些来源。默认情况下，站点B的页面不能被任何其他来源访问;使用Access-Control-Allow-Origin标题为特定请求来源的跨域访问打开了一扇门。

有关详细信息，请参阅Mozilla Developer Site

有一个chrome extension可以帮助您进行开发。

Answer 3

它是一种客户端安全机制，实际上放松安全性，而不是强化它。

默认情况下，Same Origin Policy会阻止example.com从用户的浏览器中读取对example.org的请求的响应，可选择使用{{1}的用户Cookie }}。浏览器安全模型确保尽管可以进行请求，但启动它的脚本无法读取响应中的任何数据。

示例是example.org无法向evil.example.edu发出AJAX请求，然后使用访问https://gmail.com/ajax/read_mail的浏览器读取登录Gmail的用户的电子邮件。

如果Google希望允许其他网站阅读人们的电子邮件，他们会设置一个CORS标头来放宽同源策略以允许此操作。

因此，默认情况下您更安全 - 添加evil.example.edu不会锁定任何内容 - 它允许同源策略的例外。

由于它不会改变服务器端的任何内容，因此设置标头不会影响攻击者向服务器发出的直接请求（例如使用curl）。此外，不支持CORS的旧浏览器仍然支持同源策略，因此默认情况下它们仍然是安全的＃34;在这方面。 （虽然他们可能包含现代浏览器保护的未修补的漏洞。但是，这是一个不同的故事。）