安全扫描发现前端下发的临时凭证可以执行 DeleteBucket，实际只需要往 uploads/ 前缀上传。策略文档里 Action 是 s3:*，Resource 是 *。碰到这种情况，我一般先确认改动有没有真的生效。
原因不复杂，临时凭证的权限来自扮演角色时传入的策略，写宽了就等于把整个账号的 S3 权限交给浏览器。前端代码和网络请求都能拿到这组凭证。限制只能靠策略里的 Action 和 Resource 条件。
碰到「STS 权限过大」这类问题，我习惯先把当前配置原样备份一份，改坏了立刻换回来，不用现场推。报错里带路径的，先去看那个路径在不在、权限对不对。
aws sts assume-role --role-arn arn:aws:iam::1:role/up --role-session-name web aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::1:role/up \ --action-names s3:DeleteBucket --resource-arns arn:aws:s3:::b
同一份配置存在多处的，先确认改的是被加载的那一份。新版本先放一台机器上跑一天再全量，问题一般在这段时间暴露。
备份不是备了就行，恢复一次才算数，很多备份文件打开才发现是空的。
具体做法是，Action 收窄到 PutObject 和 PutObjectTagging；Resource 精确到桶下 uploads/* 的 ARN；加条件限制对象大小和 Content-Type；用策略模拟器验证越权操作确实被拒。
最后用这个标准收尾，模拟器里 DeleteBucket 返回 implicitDeny，PutObject 到 uploads/ 返回 allowed。