为AWS API Gateway公开GET端点绑定使用计划限制调用量的安全问题及替代方案

你现在硬编码的这个API Key，本质上和你认知里的"敏感凭证"完全不是一类东西：

• 它没有绑定任何IAM权限，既没法用来调用AWS的其他服务，也没法用来访问你开启了私有认证的接口，唯一的作用就是把请求路由到对应绑定的使用计划配额上。
• 就算有人把这个Key从前端代码里扒出来，能做的唯一操作就是消耗你设定的每周10000次的调用额度，根本没法用它做任何越权操作。
• 对于教学项目来说，就算这个额度被人恶意刷满，产生的API Gateway调用成本通常不会超过1块钱，完全不存在"费用暴涨"的基础。这种情况下硬编码Key，没有实际的安全代价。

如果你还是不想在前端代码里留任何固定标识，可以选下面几个匹配你当前架构的低成本方案：

• 直接给API Gateway的部署阶段绑定全局使用计划。不对单个方法开启API Key强制校验，直接把配额、速率限制配置在整个API阶段层面，所有指向这个阶段的请求都会统一计入这个全局配额，前端不需要携带任何请求头，全程无感知。
• 前置CloudFront搭配基础WAF规则。把API Gateway的公网访问权限收紧到只允许CloudFront回源，在WAF里配置每IP的请求频率限制，同时设置域名维度的周总请求上限，完全不需要用到API Key的机制。这个方案还能挡掉80%以上来自脚本的恶意刷量。
• 用Lambda@Edge做透传代理。在你的CloudFront分发上挂一个轻量的Edge函数，当检测到前端请求指向公开端点的路径时，自动给请求追加x-api-key头再转发到API Gateway源站。前端代码里完全不会出现Key，整个链路的额外延迟基本可以忽略不计。

额外提醒：千万别给这个仅做配额关联的Key开任何额外权限，也别把同一个Key用在需要做身份校验的私有接口上，就严格把它的作用限定在"路由到对应使用计划配额"的范围内，它就永远不会产生安全风险。

内容的提问来源于stack exchange，提问作者Luca P.