在AWS Lambda中仅OPTIONS校验Origin后回显Origin是否安全？

结论先行 #

这种做法不安全，不能只靠OPTIONS预检的白名单校验，就跳过实际请求的Origin验证。

潜在风险 #

• 预检和实际请求无强制绑定：浏览器不会把通过校验的OPTIONS请求和后续的实际请求绑定死。恶意攻击者完全可以绕开OPTIONS预检（比如用Postman、curl这类非浏览器工具直接发请求），或者伪造Origin头提交实际请求，这时候你的API直接回显恶意Origin，会导致敏感数据泄露给未授权的第三方。
• 预检缓存放大风险：如果浏览器缓存了OPTIONS的响应结果，在缓存有效期内，哪怕这个Origin已经被移出白名单，实际请求依然会被允许回显Origin，相当于白名单规则失效了一段时间。
• 凭证泄露隐患：你开启了Access-Control-Allow-Credentials: true，要是随便回显Origin，浏览器会允许带凭证的请求响应被未授权的Origin获取。万一攻击者通过跨站请求伪造之类的手段触发了实际请求，用户的凭证可能会被滥用。

最佳实践 #

• 实际请求必须单独校验Origin：不管有没有过OPTIONS预检，所有POST/GET这类实际请求，都得单独检查Origin是否在白名单里，确认合法后再返回对应的Access-Control-Allow-Origin头（可以是具体域名，也可以回显这个合法的Origin）。
• 控制预检响应缓存时长：设置合理的Access-Control-Max-Age头，比如设为3600秒（1小时），既减少重复预检的性能损耗，又能避免缓存太久导致失效的白名单还在生效。
• 复用校验逻辑：把Origin白名单校验写成公共函数，OPTIONS请求和实际请求都用这个函数，避免重复写代码，也防止两边逻辑不一致出问题。
• 凭证与通配符不能共存：既然用了Access-Control-Allow-Credentials: true，就绝对不能设Access-Control-Allow-Origin: *，必须返回具体的合法Origin，这点你现在的做法是对的，但要保证校验严格。

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