将访问控制请求头设置为*，有哪些安全风险？[副本]
我们目前已经在服务器上启用了CORS，并且只允许某些源、标头和方法通过CORS。
我们计划允许通过CORS允许所有标头，即将EnableCorsAttribute.headers设置为*。
我是否应该注意任何安全问题/风险？
谢谢
共有1个答案
您不应该仅将*用作cros域，而是出于您可能认为的diffrenet原因，出于安全原因，默认情况下并非所有浏览器都允许使用通配符（*），因此您应该只返回传入请求的允许地址。
如果你提供的服务是向全世界开放的，那么这就是你应该做的，如果不是，请注意你是向全世界开放的。
-
我最近不得不将设置为，以便能够进行跨子域AJAX调用。我觉得这可能是个安全问题。如果我保持这种设置，我将面临什么样的风险？
-
问题内容： 我最近不得不设置为，以便能够进行跨子域的ajax调用。 现在，我不禁感到自己正在使环境面临安全风险。 如果我做错了，请帮助我。 问题答案： 通过使用响应，所请求的资源允许与每个来源共享。基本上，这意味着任何站点都可以向您的站点发送XHR请求并访问服务器的响应，如果您尚未实现此CORS响应，则不会这样。 因此，任何站点都可以代表其访问者向您的站点发出请求并处理其响应。如果您基于浏览器自动
-
问题内容： 在许多地方，我已经看到人们谈论过跨域XMLHttpRequest，由于某些 安全原因 ，这是不可能的。但是，我还没有找到表明这些 安全原因 实际上是什么的帖子？ 人们提到JSONP是不错的选择之一。另一种选择是使用和标头。 但是，我只想知道由于跨域XMLHttpRequest的使用会引起哪些安全问题？ 问题答案： 我认为最好回答您的问题的示例，为什么这太糟糕了。 您转到我的网站（exa
-
本任务将演示如何通过使用Istio认证提供的服务账户，来安全地对服务做访问控制。 当Istio双向TLS认证打开时，服务器就会根据其证书来认证客户端，并从证书获取客户端的服务账户。服务账户在source.user的属性中。请参考Istio auth identity了解Istio中服务账户的格式。 开始之前 根据quick start的说明在开启认证的Kubernetes中安装Istio。注意，应
-
问题内容： 默认情况下，浏览器不允许跨站点AJAX请求。 我了解，设想不正确的跨域请求 可能 会带来安全风险。如果我使用外部站点的html或javascript，然后将其“呈现”到我的网站中，那就是一个问题。该外部代码可用于处理许多不良情况，例如访问当前用户的会话数据。 但是，如果我仅请求JSON或XML数据，并且使用适当的库来解析JSON（而不仅仅是使用eval），我将无法想象这会带来安全风险。
-
本文向大家介绍redis密码设置、访问权限控制等安全设置，包括了redis密码设置、访问权限控制等安全设置的使用技巧和注意事项，需要的朋友参考一下 redis作为一个高速数据库，在互联网上，必须有对应的安全机制来进行保护。 1.比较安全的办法是采用绑定IP的方式来进行控制。 表示仅仅允许通过127.0.0.1这个ip地址进行访问。那么其实只有自己才能访问自己了，其他机器都无法访问他。 这段命令要去