浏览器报跨域错误时，很多人第一反应是修改源站；想增加 HSTS、CSP 或 X-Content-Type-Options 时，也常常直接改 Nginx 配置。这样做当然可行，但如果同一套规则要覆盖多个源站、多个缓存行为，逐个修改和发布会越来越难维护。
CloudFront 的响应标头策略（Response Headers Policy）提供了另一种处理方式：在内容返回给访问者之前，由边缘节点统一添加或删除响应标头。它可以管理 CORS、安全标头和自定义标头，也可以删除不希望暴露给客户端的标头。
不过，响应标头策略只负责“发给访问者的响应”。它不会决定缓存键，也不会代替缓存策略或源站请求策略。把几种策略的职责分清，才能避免出现 CORS 看似配置正确却仍然失败、浏览器缓存时间改变但 CloudFront 缓存没有变化等问题。
CloudFront 响应标头策略是什么？
响应标头策略是一组可以复用的响应处理规则。创建策略后，将其关联到 CloudFront 分配中的缓存行为，CloudFront 就会在向访问者返回响应时执行这些规则。
它主要能做四类事情：
添加或管理 CORS 标头，例如 Access-Control-Allow-Origin、Access-Control-Allow-Methods 和 Access-Control-Allow-Headers。
添加常用安全标头，例如 Strict-Transport-Security、Content-Security-Policy、X-Content-Type-Options 和 Referrer-Policy。
添加自定义响应标头，例如环境标识、调试标识或业务需要的固定字段。
删除源站响应中的指定标头，减少不必要的信息暴露。
响应标头策略既会应用于缓存命中返回的对象，也会应用于 CloudFront 从源站取得后返回的对象。因此，即使对象已经缓存在边缘节点，策略仍可以统一修改访问者最终收到的标头。
它和缓存策略、源站请求策略有什么区别？
这三种策略经常出现在同一个缓存行为中，但处理方向完全不同。
缓存策略
缓存策略决定哪些请求信息进入缓存键，并控制最小、默认和最大 TTL。Headers、Cookies 或查询参数一旦进入缓存键，不同取值就可能形成不同的缓存对象。
源站请求策略
源站请求策略决定 CloudFront 在缓存未命中并向源站请求内容时，还要额外转发哪些 Headers、Cookies 和查询参数。这些额外转发的值不一定进入缓存键。
响应标头策略
响应标头策略处理的是返回方向：CloudFront 准备把响应交给浏览器时，应添加、覆盖或删除哪些响应标头。
可以把一次请求简单理解为：
缓存策略判断应该用哪些请求信息查找缓存。
缓存未命中时，源站请求策略补充需要转发给源站的信息。
CloudFront 得到响应后，响应标头策略整理最终交付给访问者的标头。
一个常见误区是：在响应标头策略中添加 Cache-Control，就以为已经改变了 CloudFront 的边缘缓存时间。实际上，这个设置主要影响访问者收到的响应和浏览器缓存行为；CloudFront 自身如何缓存，仍由缓存策略、源站缓存指令及相关 TTL 规则决定。
CORS 应该如何配置？
CORS 用于控制浏览器是否允许一个来源读取另一个来源返回的资源。图片、字体、JavaScript、对象存储文件和 API 接口都可能遇到跨域问题。
在响应标头策略中配置 CORS 时，需要先回答四个问题：
哪些来源可以访问资源？
允许哪些 HTTP 方法？
浏览器可以携带哪些请求标头？
是否允许携带 Cookie 或 Authorization 等凭证？
允许的来源
公开静态资源可以使用通配符，但登录接口、用户数据接口和管理接口不适合直接允许所有来源。对于需要凭证的请求，更应该列出明确的可信域名。
例如，前端只部署在 example.com 和 app.example.com，可以将允许来源限制到这两个站点。测试域名和本地开发域名不要长期保留在生产策略中。
允许的方法
静态资源通常只需要 GET、HEAD 和 OPTIONS。API 是否需要 POST、PUT、PATCH 或 DELETE，应根据实际接口开放，不必把所有方法都加入策略。
预检请求
浏览器遇到非简单跨域请求时，通常会先发送 OPTIONS 预检。除了在 CORS 策略中允许 OPTIONS，还要确认：
CloudFront 缓存行为允许 OPTIONS 方法。
源站或边缘逻辑能够正确处理预检。
缓存键包含会影响预检响应的必要请求标头。
如果不同 Origin 会得到不同的 CORS 响应，却让它们共用同一个缓存对象，就可能把一个站点的允许结果返回给另一个站点。此时应检查 Origin、Access-Control-Request-Method 和 Access-Control-Request-Headers 是否需要参与缓存或转发。
是否覆盖源站 CORS 标头
响应标头策略中的 Origin override 决定 CloudFront 配置是否覆盖源站返回的同名 CORS 标头。
选择覆盖后，边缘策略成为统一规则，适合多个源站需要保持一致的场景。关闭覆盖时，源站已有标头会被保留，更适合源站根据用户、租户或路径动态计算 CORS 的情况。
不要让源站和 CloudFront 同时维护两套互相冲突的规则。浏览器看到重复或不一致的 Access-Control-Allow-Origin 后，仍可能拒绝请求。
常用安全标头怎么选？
CloudFront 响应标头策略可以集中添加多种浏览器安全标头，但并不是勾选越多越安全。错误的值可能导致页面资源加载失败或现有功能中断。
Strict-Transport-Security
HSTS 告诉浏览器在指定时间内只通过 HTTPS 访问站点。启用前应确认主域名和需要包含的子域名都已经稳定支持 HTTPS。
includeSubDomains 会把规则扩展到子域名；preload 还涉及浏览器预加载列表，不能只因为控制台有选项就直接开启。证书、跳转或旧子域名尚未处理好时，过早使用长期 HSTS 会增加恢复难度。
Content-Security-Policy
CSP 用于限制脚本、样式、图片、字体和其他资源可以从哪些位置加载。它很有效，也最容易因规则过严导致页面异常。
上线前先盘点实际使用的第三方统计、支付、客服、字体和图片域名。复杂网站可以先用 Content-Security-Policy-Report-Only 观察违规报告，再逐步收紧正式策略。CloudFront 的安全标头区域提供的是 Content-Security-Policy；如果要使用 Report-Only，可以通过自定义标头添加。
X-Content-Type-Options
通常设置为 nosniff，用于阻止浏览器猜测与声明不一致的内容类型。启用后应确保源站为 JavaScript、CSS、字体和下载文件返回正确的 Content-Type。
X-Frame-Options
DENY 禁止页面被任何站点嵌入框架，SAMEORIGIN 只允许同源嵌入。如果业务使用第三方登录、嵌入式控制台或 iframe 集成，应先测试。
对于需要精细控制允许嵌入来源的站点，可以结合 CSP 的 frame-ancestors 指令设计规则。
Referrer-Policy
它控制页面跳转或请求资源时携带多少来源页面信息。strict-origin-when-cross-origin 通常能在分析需求和隐私之间取得较平衡的效果，但仍应根据业务是否依赖完整 Referer 路径进行测试。
自定义标头适合放什么？
自定义响应标头适合添加固定、可公开且不包含敏感信息的字段，例如：
标记响应由哪个边缘配置版本处理。
为前端或排障工具提供公开的环境标识。
添加业务要求的固定响应声明。
补充标准策略区域未直接提供的响应标头。
不要把访问密钥、内部地址、用户标识或可用于绕过安全校验的值写入响应标头。响应标头会发送到客户端，访问者可以在浏览器开发者工具或抓包结果中看到。
自定义标头也不是动态业务逻辑的替代品。如果标头需要根据用户身份、Cookie、请求路径或源站结果动态变化，应评估 CloudFront Functions、Lambda@Edge 或源站应用是否更合适。
删除响应标头有什么用？
删除标头功能可以在不修改源站的情况下，阻止某些响应字段继续发送给访问者。例如，源站软件可能返回包含服务器类型或框架信息的标头，而客户端并不需要这些信息。
删除前要确认标头没有被浏览器、下载工具、API 客户端或监控系统使用。某些字段看起来多余，却可能参与文件下载、跨域读取、缓存控制或内容协商。
另外，CloudFront 不允许删除所有类型的标头。受限制的 HTTP 标头不能加入删除列表，具体应以控制台和当前官方文档为准。
使用托管策略还是自定义策略？
AWS 提供多种托管响应标头策略，常见方向包括：
只处理简单 CORS。
处理带预检请求的 CORS。
添加一组常用安全标头。
同时处理 CORS 与安全标头。
托管策略适合规则与官方预设一致、希望快速上线的站点。它们由 AWS 维护，但不能直接修改。
如果需要限定特定来源、调整 HSTS 时间、设计自己的 CSP、添加自定义字段或删除源站标头，就应创建自定义响应标头策略。创建前先查看托管策略的具体内容，不要只根据名称判断它是否适合生产环境。
三类常见场景的配置思路
场景一：公共静态资源
适用于公开图片、CSS、JavaScript 或下载文件。
CORS 来源可以根据业务选择明确域名或通配符。
方法通常保留 GET、HEAD、OPTIONS。
可添加 nosniff 和合适的 Referrer-Policy。
CloudFront 缓存 TTL 仍在缓存策略中配置。
场景二：需要身份凭证的 API
适用于携带 Cookie 或 Authorization 的跨域接口。
明确列出允许来源，不使用星号代替所有来源。
只开放实际使用的方法和请求标头。
确认 OPTIONS 预检请求可以正常到达并得到正确响应。
检查凭证、Origin 与缓存键之间的关系，避免不同用户或来源共享不该共享的响应。
用户私有响应不应进入公共共享缓存。
场景三：网站统一安全标头
适用于多个源站或多条缓存行为需要相同安全基线的站点。
先用测试分配或测试路径验证 CSP、HSTS 和 iframe 行为。
确定是由 CloudFront 覆盖源站标头，还是保留源站的动态结果。
对 HTML、静态资源和 API 分别测试，不要只打开首页。
上线后持续查看浏览器控制台、真实用户错误和安全报告。
配置步骤
在 AWS 管理控制台中，可以按以下顺序操作：
打开 CloudFront，进入 Policies 下的 Response headers。
选择使用 AWS 托管策略，或创建自定义响应标头策略。
根据需要配置 CORS、安全标头、自定义标头和删除标头。
打开目标 Distribution，编辑对应的 Cache behavior。
在 Response headers policy 中选择刚才的策略并保存。
等待配置部署完成后，从实际访问域名进行验证。
修改策略前，先确认它被哪些缓存行为复用。一个自定义策略可能同时关联多个分配，直接修改会影响所有关联行为。如果只想调整其中一个站点，可以复制为新策略后再关联。
如何验证配置是否生效？
只在控制台看到“已部署”还不够，至少要分别测试普通请求、缓存命中请求和 OPTIONS 预检请求。
普通响应可以使用：
curl -I https://www.example.com/app.js
测试指定 Origin：
curl -I https://www.example.com/app.js \ -H "Origin: https://app.example.com"
测试预检请求：
curl -i -X OPTIONS https://api.example.com/v1/data \ -H "Origin: https://app.example.com" \ -H "Access-Control-Request-Method: POST" \ -H "Access-Control-Request-Headers: Authorization,Content-Type"
检查结果时关注 Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers、Strict-Transport-Security、Content-Security-Policy、X-Content-Type-Options 和 Referrer-Policy。
还要对比缓存命中与未命中的响应是否一致。如果修改后仍看到旧标头，先确认策略是否关联到正确的缓存行为、请求路径是否命中预期行为，以及浏览器或中间代理是否保存了旧响应。
常见错误
把响应标头策略当成缓存策略
响应标头策略可以向客户端添加 Cache-Control，但不能单独决定 CloudFront 的边缘缓存键和 TTL。缓存问题应同时检查缓存策略和源站缓存指令。
CORS 使用通配符并同时允许凭证
需要 Cookie 或其他凭证的跨域请求，应返回明确的允许来源，并配合正确的 Access-Control-Allow-Credentials。直接使用通配符通常不能满足浏览器的凭证请求要求。
源站与 CloudFront 返回冲突标头
没有明确设计覆盖规则时，可能出现重复标头或两个不同的允许来源。应确定唯一的规则来源，或保证两边逻辑一致。
所有路径共用一套策略
HTML 页面、公共静态资源和私有 API 的风险不同。为了减少误配，可以按缓存行为分别关联策略，而不是为了省事让所有路径共享同一套规则。
直接在生产环境开启严格 CSP
没有盘点第三方资源就启用严格 CSP，可能导致脚本、字体、支付组件或客服工具被浏览器拦截。先观察、再收紧更稳妥。
总结
CloudFront 响应标头策略适合统一管理 CORS、安全标头、自定义标头和标头删除规则。它的优势是策略可复用，并且能在边缘节点统一整理最终响应；它的边界也很清楚：不负责定义缓存键，不代替源站请求策略，也不能单独改变 CloudFront 的缓存 TTL。
实际配置时，先按资源类型区分公共静态文件、带凭证 API 和 HTML 页面，再决定允许来源、覆盖规则和安全标头。上线前测试预检请求、缓存命中响应和主要页面功能，往往比一次勾选所有安全选项更可靠。
CloudFlew 提供基于 AWS CloudFront 的 CDN 服务。需要为网站接入 CDN、统一配置 HTTPS 或优化全球访问时，可前往 CloudFlew CDN 产品页面查看当前服务信息。
参考资料
AWS CloudFront Developer Guide：Understand response headers policies
AWS CloudFront Developer Guide：Use managed response headers policies
AWS CloudFront Developer Guide：Add or remove HTTP headers in CloudFront responses with a policy
MDN Web Docs：Cross-Origin Resource Sharing (CORS)
