Google App Engine技术问询：在基于令牌的公开API中使用Datastore URL安全实体键作为匿名ID是否存在安全风险？

一、为什么不建议用Datastore URL安全实体键作为匿名ID？ #

虽然URL安全键看起来是编码后的字符串，但它并非设计用来做匿名ID，存在以下几个关键风险：

• 暴露实体元数据：URL安全键是对实体键的base64编码，解码后可以直接获取实体的kind（实体类型）和内部ID/名称。比如如果你的实体kind是Customer，攻击者解码后就能知道这个ID对应的是客户实体，可能结合其他公开信息进行针对性攻击。
• 可枚举性风险：如果你的实体使用Datastore自动生成的整数ID，那么URL安全键里的ID部分是递增的。攻击者可以通过遍历ID的方式，批量枚举所有实体对应的匿名ID，进而尝试访问API获取关联数据。
• 无法轮换：URL安全键和实体是永久绑定的，一旦泄露就无法更改（除非删除重建实体）。而专门生成的匿名ID（比如UUID）可以定期轮换，即使旧ID泄露，也不会影响实体的后续安全。
• 业务信息泄露：有些场景下，实体kind的命名可能包含敏感业务逻辑（比如PremiumUser），解码后会直接暴露这类信息，增加信息泄露的风险。

二、只要不直接对外提供实体键，GAE与Datastore是否安全？ #

可以认为是相对安全的，但前提是你做好了完整的安全防护措施，不能只依赖隐藏实体键：

• 核心安全基础：GAE和Datastore本身的安全模型是基于IAM权限的，只要正确配置了服务账号的权限（比如限制服务账号只能访问特定实体类型、特定命名空间），外部没有权限直接通过实体键访问数据——因为没有合法的身份凭证，即使拿到键也无法调用Datastore API。
• 需要补充的防护层：
  • 做好API的身份验证与授权：确保只有合法用户能访问API，且每个用户只能访问自己有权限的实体，不能通过参数遍历等方式获取其他实体数据。
  • 避免间接泄露实体键：比如不要在错误日志、API响应的错误信息里返回实体键，也不要在前端代码或客户端存储中留下键的痕迹。
  • 防护常见攻击：比如对API输入做严格验证，防止NoSQL注入；启用GAE的安全防护功能（比如App Engine Firewall），阻挡恶意请求。
• 注意索引风险：如果Datastore的索引包含敏感数据，即使不暴露实体键，攻击者也可能通过查询索引获取敏感信息，所以要合理配置索引，避免存储不必要的敏感字段。

总结建议 #

最好不要用URL安全键作为匿名ID，建议在实体中新增一个字段存储专门生成的随机匿名ID（比如UUID v4），这样既可以实现匿名标识，又能避免上述风险。同时，安全是多层防护的结果，隐藏实体键只是其中一环，还要结合IAM配置、API授权、输入验证等措施，才能保障GAE和Datastore的整体安全。

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