如何保障从公共计算机向服务器传输用户ID的安全性？

这确实是公共计算机环境下很典型的身份伪造风险，咱们可以从前端到后端搭建多层防护来解决这个问题，具体方案如下：

1. 用短期认证令牌替代明文用户ID #

别再直接传明文用户ID了，换成**短期有效的JWT（JSON Web Token）**或者会话令牌：

• 用户登录或初始化会话时，后端生成包含用户ID、过期时间（比如15分钟）、后端私钥签名的JWT，把它存在HttpOnly+Secure的Cookie里——这样前端JS根本读不到，也就不会在Network tab里暴露。
• 前端每次发请求，Cookie会自动携带，后端先验证JWT的签名是否合法、有没有过期，没问题再解析出用户ID去调用GCP服务。
• 要是担心令牌过期影响体验，还可以搭配刷新令牌机制，令牌快过期时自动静默续期，不用用户重新登录。

2. 给请求加签名验证，防篡改和重放 #

让每个请求都带上唯一的合法签名，后端校验通过才处理：

• 后端给每个会话分配一个仅存在后端的临时签名密钥（和用户会话绑定，过期就失效）。
• 前端发起请求时，用这个密钥对请求参数（比如当前时间戳、请求路径、令牌片段）做HMAC哈希，生成签名放在请求头里。
• 后端收到请求后，先用相同的参数和存储的密钥重新计算签名，和前端传来的比对；同时校验时间戳，拒绝5分钟前的请求，防止攻击者重放旧请求。
• 划重点：这个签名密钥绝对不能传给前端，只能后端自己维护，前端只需要用后端返回的“签名生成规则”（比如用什么哈希算法）来生成签名就行。

3. 限制请求来源，只认你的官方前端 #

通过CORS和请求头校验，把第三方网站的伪造请求挡在外面：

• 后端配置CORS规则，只允许你的官方域名（比如https://your-web-app.com）发起跨域请求，其他域名直接拒绝。
• 同时检查请求头里的Origin字段，只有匹配你的合法域名的请求才处理——Referer虽然也能用来校验，但可能被浏览器或代理屏蔽，Origin更可靠。
• 注意要把开发、测试、生产环境的域名都加到白名单里，别自己把正常请求挡住了。

4. 结合设备指纹与行为分析，增加验证维度 #

让冒充者就算拿到令牌，也过不了设备和行为这一关：

• 后端记录用户的设备指纹（比如浏览器UA、屏幕分辨率、操作系统信息的哈希值），和会话令牌绑定。
• 每次请求时，后端比对当前请求的设备指纹和会话绑定的指纹，如果不一致，就触发二次验证（比如短信验证码、邮箱验证），或者直接拒绝请求。
• 还可以加请求频率限制，比如1分钟内超过10次请求就拦截，异常地理位置的请求也触发预警。

5. 用映射ID隔离真实用户ID #

就算前面的措施都被绕过，也别让攻击者拿到真实的业务用户ID：

• 后端维护一个“真实用户ID ↔ 临时映射ID”的对照表，映射ID和会话绑定，每次会话结束就失效。
• 前端只知道映射ID，就算被窃取，攻击者也没法关联到真实用户的业务数据；后端收到映射ID后，再转换成真实用户ID去调用GCP TTS服务。

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