无反向代理时，设置CloudFront签名Cookie访问私有S3的方案是否可行？

需求背景 #

我正在构建一套通过CloudFront签名Cookie提供私有S3资源访问的系统，目标是让终端用户无需生成单个预签名URL，就能直接浏览整个S3文件夹内容。

我的实现方案 #

• 已部署CloudFront分发，地址为https://d1234abcdef.cloudfront.net
• 用户登录后，前端SPA调用/api/getAccessToken接口，后端执行以下逻辑：
  • 校验用户的角色与权限
  • 生成一个单次使用、短TTL的令牌（access_id）
  • 返回构造好的跳转URL：

    https://d1234abcdef.cloudfront.net/set-cookies.html?access_id=<UUID>&Signature=...
    

• 部署在同一CloudFront分发下的静态文件set-cookies.html包含内联JS，执行流程：
  • 从URL查询字符串中提取access_id
  • 调用后端/api/redeem?access_id=接口，后端处理：
    • 验证access_id的有效性，并立即将其标记为过期（防止重复使用）
    • 返回CloudFront签名Cookie所需的三个值：Policy、Signature、Key-Pair-Id
  • 设置Cookie，属性配置为Secure; HttpOnly; SameSite=None; Path=/，作用域为d1234abcdef.cloudfront.net
• Cookie设置完成后，页面重定向回前端SPA

排除其他方案的原因 #

• 反向代理（如app.example.com 反向代理到CloudFront）：会完全丧失CDN的流量卸载优势，大幅增加用户访问延迟
• 自定义CNAME+父域Cookie（如cdn.example.com 使用.example.com域的Cookie）：浏览器仅允许在同一主机名或父域下设置Cookie；由于我们存在多个面向公众的子域，无法安全设置.example.com级别的Cookie，避免所有子域应用都继承该签名Cookie带来的安全风险
• Lambda@Edge或API Gateway JWT认证：技术上可行，但会增加每请求的计算成本，同时提升了部署和测试的复杂度

待解答问题 #

1. 这套方案是否具备可行性与合理性？
2. 该方案存在哪些潜在的陷阱或缺陷？

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