前端源码硬编码Amazon Cognito的UserPoolId与ClientId是否存在安全问题？

核心结论 #

在网页源码中硬编码Amazon Cognito的UserPoolId和ClientId不属于安全配置错误，但如果允许未授权用户仅凭这些ID就能无限制创建用户，那就是明确的不良实践，会带来实际安全风险。

具体分析 #

• UserPoolId和ClientId的性质：这两个值本身就是Cognito设计中允许公开的标识符，用于唯一标识用户池和客户端应用，并非敏感凭据（类似数据库连接串里的用户名，而非密码）。AWS官方设计逻辑里，前端应用使用Cognito时，这两个值本来就需要暴露在客户端代码中，硬编码是常规操作。

• 未授权用户创建用户的风险来源：问题的核心不在ID的公开，而在用户池的权限配置：

  • 如果你的Cognito用户池开启了无验证的公开注册（比如允许匿名用户直接创建账号，且没有邮箱/短信验证码、人机验证等限制），才会导致垃圾注册、恶意账号泛滥等安全问题，这属于不良配置实践。
  • 正确的做法是：要么关闭公开注册，仅允许内部授权渠道创建用户；要么给注册流程增加强验证环节，确保注册请求来自真实用户；同时可通过Cognito客户端设置，限制允许发起请求的域名、授权范围等，进一步降低风险。

• 前端使用Cognito的正确姿势：前端应用应使用Cognito的**公共客户端（Public Client）**模式，这种模式下不需要存储Client Secret（前端无法安全保存敏感密钥），UserPoolId和ClientId就是要放在前端代码中的常规配置项，这是符合AWS设计规范的用法。

内容的提问来源于stack exchange，提问作者Швець Максим