CloudFront分发与Route53托管域名场景下，Access-Control-Allow-Origin头部应配置哪个地址？

首先直接给结论：你应该将Access-Control-Allow-Origin头部设置为你的自定义域名https://example.com，而不是CloudFront的分发URLhttps://abcdef.cloudfront.net/，原因和两者的生效性分析如下：

为什么选自定义域名？ #

你的前端应用是通过https://example.com对外提供服务的——这是用户实际访问、浏览器识别的「来源域名」。CORS机制的核心是验证请求发起页面的Origin与服务端返回的Access-Control-Allow-Origin是否匹配：

• 当用户在https://example.com页面发起API请求时，浏览器会自动在请求头里带上Origin: https://example.com
• 如果你的Lambda返回的Access-Control-Allow-Origin是这个自定义域名，浏览器会判定权限合法，允许跨域请求；如果设成CloudFront的URL，浏览器会认为Origin不匹配，直接拦截响应，导致CORS失败。

二者是否均可生效？ #

答案是只有自定义域名能生效。CloudFront的分发URL只是CDN的入口，你的前端代码并不部署在这个域名下，用户也不会直接访问它（Route53已经把自定义域名解析到了CloudFront），所以浏览器发起请求时的Origin永远是https://example.com，设置CloudFront的URL完全无法通过浏览器的CORS校验。

额外的安全优化建议 #

• 不要硬编码域名：可以在Lambda中动态获取请求的Origin头，然后校验它是否属于你允许的域名列表（比如只允许https://example.com和https://app.example.com），再返回对应的Access-Control-Allow-Origin值，这样扩展性更强。
• 如果需要支持凭证（比如Cookie、HTTP认证）：记得同时设置Access-Control-Allow-Credentials: true，但此时Access-Control-Allow-Origin绝对不能用*，必须是具体域名。
• 配合CloudFront的CORS配置：你也可以在CloudFront层统一配置CORS规则，替代Lambda里的头部设置，这样更便于集中管理所有跨域请求策略。

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