浏览器端调用Google逆地理编码API时如何限制API Key

Geocoding属于Google Web Service类API，原生不支持HTTP Referer维度的请求来源校验，硬从浏览器直连API的场景下，不存在能完全等效域名限制的密钥管控手段，可落地的安全方案按优先级排序：

• 首选方案：后端反向代理中转请求
  • 完全不将Google Geocoding的API密钥硬编码在前端浏览器可访问的代码中
  • 在自有服务端搭建轻量中转接口（可基于任意后端技术栈实现，示例路径如/internal/reverse-geocode）
  • 前端请求逻辑调整为：浏览器仅向自有域名下的中转接口发送经纬度参数，不直接请求Google的API地址
  • 服务端中转逻辑：校验请求合法性后，携带做了IP白名单限制的Google Geocoding密钥，向Google官方接口发起请求，拿到返回结果后透传给前端
  • 该模式下，请求Google API的源IP是自有服务的固定公网出口IP，完全适配Google对Web Service API的IP限制规则，不存在密钥泄露的风险
  • 可在中转层叠加额外防护：来源Referer校验、单IP请求频率限制、参数合法性校验，进一步压缩密钥被滥用的可能
• 直连场景下的临时风险兜底（不推荐长期使用）
  若因架构限制暂时无法搭建中转层，必须从浏览器直连Geocoding接口，需明确该场景下无法实现Google原生的域名维度限制，仅能做最低限度的风险控制：
  • 单独为Geocoding接口申请专用密钥，仅开放Geocoding对应的API调用权限，从权限层面压缩泄露后的影响范围
  • 在密钥管控页设置明确的调用额度上限（按实际业务量设置日/小时级阈值），开启账单告警，就算密钥被非法盗用，最多只会消耗完预设额度，不会产生无上限的异常账单
  • 开启调用行为日志监控，发现异常高频调用时立刻轮换密钥
• 常见误区澄清
  不要将Google Maps JavaScript API的密钥管控规则与Web Service类API的规则混淆：
  • 加载Google Maps JS SDK时使用的密钥支持Referer域名限制，SDK内部封装的逆地理编码能力走JS专属链路，校验规则可正常生效
  • 只要是通过fetch、axios等前端HTTP方法直接请求maps.googleapis.com/maps/api/geocode/json这个独立Web Service地址，就属于纯服务端调用链路，不受Referer规则保护，就算给密钥配置了Referer限制，Google也会直接抛出API keys with referer restrictions cannot be used with this API的错误

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