为公共和只读网络服务启用 CORS 是否安全? [英] Is it safe to enable CORS to * for a public and readonly webservice?

查看:16
本文介绍了为公共和只读网络服务启用 CORS 是否安全?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

启用 CORS 有几个安全问题:

Enabling CORS has several security issues:

  • CSRF
  • 暴露受保护的数据

但是对于启用全局 CORS 的公共只读 Web 服务是否存在任何问题?

But are there any issues for a public and readonly webservice to enable global CORS?

Access-Control-Allow-Origin: *

我的假设:

  • CSRF 不相关,因为网络服务是只读的.
  • 窃取受保护数据无关紧要,因为网络服务是公开的.

推荐答案

这里是 与 Fetch 规范相关的内容(定义了 CORS):

Here’s something relevant from the Fetch spec (which defines CORS):

对于通过 IP 身份验证或防火墙(不幸的是仍然相对常见)保护数据的资源,使用 CORS 协议是不安全的.(这就是必须要发明 CORS 协议的原因.)

Basic safe CORS protocol setup

For resources where data is protected through IP authentication or a firewall (unfortunately relatively common still), using the CORS protocol is unsafe. (This is the reason why the CORS protocol had to be invented.)

但是,否则使用以下标头是安全的:

However, otherwise using the following header is safe:

Access-Control-Allow-Origin: *

即使资源基于 cookie 或 HTTP 身份验证公开了附加信息,使用上述标头也不会显示它.它将与 XMLHttpRequest 等 API 共享资源,就像它已经与 curlwget 共享一样.

Even if a resource exposes additional information based on cookie or HTTP authentication, using the above header will not reveal it. It will share the resource with APIs such as XMLHttpRequest, much like it is already shared with curl and wget.

换句话说,如果无法从使用 curlwget 连接到网络的随机设备访问资源,则不会包含上述标头.但是,如果它可以访问,那么这样做完全没问题.

Thus in other words, if a resource cannot be accessed from a random device connected to the web using curl and wget the aforementioned header is not to be included. If it can be accessed however, it is perfectly fine to do so.

Fetch/CORS 规范的作者在相关博客文章中详细介绍了:

And the author of the Fetch/CORS spec goes into a bit more detail in a related blog posting:

使用 Access-Control-Allow-Origin: * 扩充任何资源是完全安全的,只要该资源不属于内联网(在防火墙后面).换句话说,您可以使用 wgetcurl 从 Internet 上的服务器获取的 URL.对于您的基本网站,这包括网站上的所有资源.Access-Control-Allow-Origin 标头(CORS 的一部分)告诉浏览器可以共享资源.

It is completely safe to augment any resource with Access-Control-Allow-Origin: * as long as the resource is not part of an intranet (behind a firewall). In other words, a URL you can fetch from a server on the internet using wget or curl. For your basic web site this encompasses all resources on the site. The Access-Control-Allow-Origin header (part of CORS) tells the browser the resource can be shared.

即使资源在请求中包含基于 cookie 或 HTTP 身份验证数据的机密信息,包括标头和共享资源仍然是安全的,因为浏览器将在没有任何 cookie 或 HTTP 身份验证数据的情况下发出请求.如果浏览器确实使用 cookie 或 HTTP 身份验证数据发出请求,它永远不会共享资源,因为这将需要一个额外的标头,Access-Control-Allow-Credentials,以及不同的值前面提到的标题.

Even if the resource includes confidential information based on cookies or HTTP authentication data in the request, including the header and sharing the resource is still safe, since the browser will make the request without any cookies or HTTP authentication data. And if the browser did make the request with cookies or HTTP authentication data, it would never share the resource because that would require an additional header, Access-Control-Allow-Credentials, and a different value for the aforementioned header.

因此,请继续安全地与其他应用程序共享您的公共数据!

So go ahead and safely share your public data with other applications!

这篇关于为公共和只读网络服务启用 CORS 是否安全?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆