S3 Delete Object REST API返回403 仅Principal设为*时可正常删除

你遇到403的核心问题是当前用HTTPoison发起的DELETE请求属于匿名请求，没有携带AWS SigV4签名认证信息，S3无法识别请求发起者的身份，自然匹配不到你配置中给指定IAM用户的授权规则，直接拒绝访问。
对应你观察到的现象可以直接印证：

• 把存储桶策略第二条的Principal改成*时能正常删除：因为这个配置等于放开匿名用户的删除权限，不需要身份校验，裸请求自然能通过，注意这个配置风险极高，生产环境绝对不能用。
• AWS CLI可以正常删除：因为CLI会自动读取本地配置的IAM用户AK/SK，对所有请求自动完成SigV4签名，S3能正确识别请求对应的IAM用户身份，自然能匹配权限放行。
• 你当前代码里只加了x-amz-expected-bucket-owner头，这个头仅用于校验存储桶所属账号，完全不具备身份认证作用，S3收到的还是无身份标识的匿名请求。
  另外你存储桶策略里的两个桶资源占位符<MY_BUCKET>和<BUCKET_NAME>要确认都替换成了真实的、一致的桶名，不要留占位符或者拼写错误，这也是潜在的配置坑。

推荐方案：使用成熟的AWS SDK调用S3接口 #

不要自己裸写HTTP请求调用S3 API，直接用维护成熟的AWS SDK自动处理签名、请求封装逻辑，避免手动实现签名的各种坑：

1. 在mix.exs中添加依赖：

defp deps do
  [
    {:aws, "~> 1.0"},
    {:aws_s3, "~> 0.3"}
  ]
end

2. 用你持有的IAM用户AK、SK、存储桶所在区域初始化客户端，直接调用删除对象接口即可，SDK会自动处理SigV4签名、必填请求头、错误封装等逻辑，不需要手动拼接HTTP请求。

可选方案：手动实现SigV4签名后再发请求 #

如果你有特殊需求必须自己用HTTPoison封装请求，必须严格按照AWS SigV4签名规范，对请求方法、路径、请求头、请求体做哈希签名，把签名结果放到Authorization请求头中，同时携带x-amz-date等必填头，S3才能正确识别你的IAM用户身份，匹配存储桶策略和IAM附加的AmazonS3FullAccess权限放行。

注意：手动实现SigV4签名很容易因为URL编码、请求头排序、时间戳偏差、签名串拼接顺序错误导致签名失败，非特殊场景不推荐自己实现。

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