当前位置: 首页 > 知识库问答 >
问题:

将访问控制请求头设置为*,有哪些安全风险?[副本]

平羽
2023-03-14

我们目前已经在服务器上启用了CORS,并且只允许某些源、标头和方法通过CORS。

我们计划允许通过CORS允许所有标头,即将EnableCorsAttribute.headers设置为*。

我是否应该注意任何安全问题/风险?

谢谢

共有1个答案

爱繁
2023-03-14

您不应该仅将*用作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地址进行访问。那么其实只有自己才能访问自己了,其他机器都无法访问他。 这段命令要去