设置Access-Control-Allow-Headers: *存在哪些安全影响？

配置Access-Control-Allow-Headers: *虽然能快速解决Request header field Pragma is not allowed by Access-Control-Allow-Headers in preflight response这类跨域预检查报错，但属于过度宽松的CORS策略，存在以下明确安全隐患：

• 敏感请求头滥用风险：通配符*允许任意自定义请求头传入，攻击者可通过恶意站点构造带自定义请求头的跨域请求，利用受害者浏览器中存储的登录态Cookie、身份凭证等，向你的服务端提交恶意操作。如果你的服务端原本依赖自定义请求头做CSRF防护，这种配置会直接让防护逻辑失效，攻击者可轻松伪造合法请求完成越权操作。
• 未授权接口访问风险：如果你的服务端存在仅限内部系统、特定前端版本调用的接口，且这类接口通过自定义请求头做鉴权、版本校验、链路标识，通配符配置会允许攻击者自由构造符合要求的请求头，绕过访问限制直接调用敏感接口，非法获取或修改业务数据。
• 缓存投毒风险：允许Pragma、Cache-Control这类缓存控制类请求头无限制传入，攻击者可构造特殊的缓存控制参数，诱导CDN、反向代理层缓存恶意构造的响应内容，后续所有访问该资源的正常用户都会拿到被篡改的内容，触发XSS、钓鱼、数据窃取等攻击。
• 合规风险：网络安全等级保护、数据安全相关法规明确要求网络服务需遵循最小权限原则配置访问控制规则，过度宽松的CORS配置会被判定为高危安全漏洞，导致合规测评不通过，甚至面临监管处罚。

生产环境优化建议 #

不要使用通配符放行所有请求头，遵循最小权限原则仅放行业务实际用到的请求头即可，示例配置如下：

Access-Control-Allow-Headers: Content-Type, Pragma, Cache-Control, X-Requested-With, 其他业务自定义请求头

内容的提问来源于stack exchange，提问作者Lawrence Pang