已配置CORS规则的AWS S3预签名POST请求仍被跨域拦截

核心现象匹配 #

所有排查结果都指向同一个本质逻辑：

• 无跨域限制的客户端（Postman、curl、复刻请求的独立HTTP客户端）发起实际POST请求可连通、可正常上传
• 浏览器端发起请求时，在预检阶段就触发缺失Access-Control-Allow-Origin的报错
• 关闭浏览器CORS校验后请求流程可正常走完

高频根因定位 #

1. S3 CORS规则遗漏OPTIONS方法配置
   浏览器触发跨域上传时，会优先发送OPTIONS预检请求，但多数人配置S3 CORS时只会加GET/PUT/POST/DELETE四个方法，偏偏漏掉OPTIONS。这种场景下S3收到OPTIONS请求根本不会返回任何CORS响应头，直接被浏览器拦截——这和测试时的现象完全匹配：curl、Postman这类工具不会发预检请求，直接发POST的时候能匹配到POST方法的规则完成连通，只是因为参数不规范没实际把文件写到桶里，所以看着像是“连通了但没有文件”。
2. 允许的来源字符串不精确匹配
   现有配置里的来源值为https://mydomain.or，首先核对是否为域名拼写偏差（比如漏写后缀的字母，实际应为https://mydomain.org）。S3的CORS来源是完全字符串匹配，不做模糊兼容：
   • 协议差（http/https不互通）
   • 域名差（带www/不带www不互通）
   • 端口差（同域名不同端口不互通）
     只要来源值和请求头里的Origin值有一点差异，S3就不会返回对应的CORS头。
3. formData字段顺序错误导致S3校验失败，返回不带CORS头的错误响应
   S3对预签名POST的表单字段顺序有强制要求：必须把后端返回的所有预签名表单字段（Key、Policy、Signature、安全令牌等）放在文件字段之前。如果把文件字段放在formData的最前面，S3会直接返回403错误，而S3对所有4xx/5xx错误默认不附带CORS响应头，此时浏览器会把这个错误统一报为CORS拦截，掩盖真实的参数错误。

分步修复验证流程 #

• 第一步：修正S3存储桶的CORS规则，完整配置包含以下内容：
  • 允许来源：和前端实际请求的Origin值完全一致（逐字符核对，不要漏后缀、协议、端口）
  • 允许方法：GET, PUT, POST, DELETE, OPTIONS
  • 允许请求头：*
  • 允许响应头：ETag
  • 预检最大缓存时长：3600秒，减少重复预检请求
• 第二步：核对formData的拼接逻辑，确保所有后端返回的预签名字段先追加到formData，最后再追加文件字段
• 第三步：不要手动在请求头中设置Content-Type，交由浏览器自动生成带boundary的multipart头，避免手动设置导致boundary与表单内容不匹配
• 第四步：确认后端生成预签名POST的服务器时间与UTC时间偏差不超过5分钟，时间偏差过大会导致S3校验签名失败，返回不带CORS头的错误

常见误区：CORS报错不一定是跨域配置的问题，只要S3返回的响应没有附带CORS头，不管实际错误是参数错误、权限错误、时间错误，浏览器都会统一抛出“CORS策略拦截、缺失Access-Control-Allow-Origin”的提示。

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