S3 CORS权限异常：未指定方法可执行、仅设GET却能PUT对象

这两个问题其实都指向同一个关键认知：S3的CORS配置只对浏览器发起的跨域请求生效，不是所有访问S3的请求都会受它约束。我来分别拆解：

问题1：为何S3 CORS允许使用我在配置中未指定的方法？ #

• 首先得明确CORS的本质：它是浏览器的安全机制，用来限制前端页面从其他域名获取资源的行为，只针对浏览器发起的跨域请求。
• 如果你是用AWS CLI、后端SDK（比如boto3、AWS SDK for Java）、Postman这类非浏览器工具调用S3 API，这些请求完全不受CORS规则限制——只要你的IAM身份（用户/角色）有对应的操作权限，就能执行任何允许的动作，不管CORS配置里写了啥方法。
• 另外，浏览器的请求还分两种：
  • 简单请求（比如GET、HEAD，或者满足特定条件的POST）：这类请求不会先发送OPTIONS预检请求，S3会先执行操作，再返回CORS响应头。浏览器会根据这些头决定是否允许前端读取响应结果，但操作本身已经完成了。
  • 预检请求（OPTIONS）：只有这类请求会触发S3的CORS规则校验，如果配置里没允许对应方法，浏览器会直接拦截后续的实际请求。

问题2：为何我仅在允许方法中指定了GET，却仍能通过PUT请求上传对象？ #

• 最常见的原因：你用的是非浏览器工具发起PUT请求。比如用aws s3 cp命令、Postman或者后端服务上传，这些场景下CORS配置根本不起作用——只要你的IAM策略/桶策略允许s3:PutObject权限，就能成功上传。
• 如果是在浏览器里发起的PUT请求却成功了，那得排查几个点：
  • 请求是不是同域的？如果你的页面域名和S3桶的访问域名（比如your-bucket.s3.amazonaws.com）是同源，或者你通过CloudFront等配置了同源规则，那浏览器不会触发CORS检查，自然能执行PUT。
  • 有没有不小心配置错了CORS规则？比如是不是把AllowedMethods设成了["*"]，或者配置了多条规则其中一条包含PUT？可以用命令aws s3api get-bucket-cors --bucket your-bucket-name查看当前生效的配置，确认是否存在疏漏。
• 最后一定要区分：CORS是浏览器端的响应读取限制，不是S3的操作权限控制。真正管控S3操作权限的是IAM策略、桶策略、对象ACL这些机制，CORS不会阻止S3执行操作，只是阻止浏览器前端读取不符合规则的响应结果。

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