谁设定了交叉原产地政策?

时间:2014-12-08 17:16:02

标签: security cors

根据我一直以来的理解,您的浏览器决定是否允许跨源请求。

我理解的方式如下:

  

您的浏览器会从服务器请求某个网站   www.billswebsite.com。服务器发回一个页面。如果页面   尝试让您的浏览器从其他地方请求数据   恶意可能会继续,所以你的浏览器决定你不要   向您最初输入的网站发出请求。

然而,我遇到了这个网站http://jsonplaceholder.typicode.com/,声称他们最终关闭了CORS的限制。

我不知道他们是怎么做到的。为什么这样的事情的责任落在提供者的手中?任何恶意网站都可以允许CORS并窃取您的数据,或者至少将您的计算机指向您不想去的地方。

有人可以澄清整件事情是如何运作的吗?

1 个答案:

答案 0 :(得分:2)

当服务器使用CORS时,它打开了一扇门,可以跨域访问自己的资源。当站点A提供CORS头时,这意味着其他一些源可以读取站点A上的资源。

您的担忧

  

任何恶意网站都可能只允许CORS并窃取您的数据

有点像担心

  

拥有房屋的任何邪恶罪犯都可以将自己的门打开,然后轻松地走进你的家中并偷东西

罪犯已将自己家的门打开了;你的门完全不受影响。如果一个邪恶的网站提供CORS标题,那么其他来源可以访问该邪恶网站上的资源;这不是双向许可。

每当浏览器脚本使用AJAX请求跨源资源时,拥有该资源的服务器可以提供Access-Control-Allow-Origin CORS响应头,以允许对该特定资源进行跨源访问。当浏览器获得响应时,它会检查请求脚本是否已从CORS响应允许的原点运行。如果匹配,则允许脚本查看响应;如果没有,则被拒绝。

例如,billswebsite.com运行一个尝试获取http://example.com/foo.txt的脚本。 example.com服务器在服务Access-Control-Allow-Origin时可以在响应中发送foo.txt标头。当浏览器获得HTTP响应时,它会检查Access-Control-Allow-Origin*还是billswebsite.com。如果Access-Control-Allow-Origin标头不匹配或完全丢失,则billwebsite.com上的脚本无法读取响应。