浏览器端HTML5游戏FireStore安全防护：如何阻止恶意请求篡改？

一、强化Firestore安全规则的校验逻辑 #

仅验证登录状态和数据归属远远不够，需要补充以下规则校验：

• 操作合理性校验：根据游戏逻辑限制数据变更范围，比如得分只能递增且单次增幅不超过游戏设定的上限。示例规则：

  allow update: if request.auth.uid == resource.data.userId &&
    request.resource.data.score > resource.data.score &&
    (request.resource.data.score - resource.data.score) <= 100; // 单次最多加100分
  

• 字段白名单校验：限制用户仅能修改指定字段，防止篡改系统级数据。示例规则：

  allow update: if request.resource.data.keys().hasOnly(['score', 'coins', 'lastUpdated']);
  

• 操作频率限制：通过记录lastUpdated字段，限制单位时间内的操作次数，防止批量刷数据。示例规则：

  allow update: if request.time > resource.data.lastUpdated + duration.value(30, 's'); // 30秒内仅允许一次更新
  

二、引入后端中转验证（核心防护手段） #

前端直接操作Firestore的模式本质上不安全，必须通过自有后端服务中转所有写操作：

• 游戏内触发数据更新的操作（如完成关卡、领取奖励），先将操作信息（如关卡ID、操作类型）发送到你的后端API
• 后端完成以下校验后，再通过Firebase Admin SDK修改Firestore数据：
  • 解码并验证用户的Firebase Auth ID Token，确认身份合法性
  • 根据游戏逻辑校验操作真实性（如用户是否已解锁该关卡、是否满足奖励领取条件）
  • 计算合法的数值变更（如应增加的得分、道具数量），避免直接使用前端传来的数值
• 此模式下前端无法直接接触Firestore写接口，篡改请求会被后端直接拦截。

三、请求签名/一次性令牌机制（后端中转的替代方案） #

若无法完全依赖后端中转，可通过签名令牌限制合法请求：

• 前端发起数据更新前，先向后端请求一次性令牌，后端生成令牌时绑定用户ID、允许的操作类型、数值范围及有效期
• 前端携带令牌与操作数据提交至Firestore，安全规则中校验令牌的合法性（可将令牌存储在Firestore临时集合，规则中检查令牌存在、匹配用户、未过期且符合操作约定）
• 令牌使用后立即标记为失效，防止重复利用。

四、后端兜底审计 #

即使有前端和规则校验，仍需通过后端定时任务做数据审计：

• 定期扫描用户数据，排查异常值（如得分远超正常游戏进度、道具数量不符合获取逻辑）
• 发现异常数据直接回滚，并记录用户行为，必要时限制账号操作权限。

五、前端反篡改优化（提升攻击成本） #

虽然无法彻底阻止，但能增加攻击者的篡改难度：

• 对游戏JS代码进行混淆压缩，使用Terser、JavaScript Obfuscator等工具，降低代码可读性
• 加入反调试逻辑，比如检测开发者工具是否开启，一旦触发则限制游戏功能（如暂停运行、清空进度）

易遗漏的防护要点 #

• 所有游戏核心逻辑（如得分计算、奖励规则）必须放在后端，禁止在前端暴露敏感逻辑
• 不要信任任何前端传入的数据，哪怕是看似无关的字段（如关卡等级），都需要后端验证合法性
• 留存所有关键操作的日志（后端API日志、Firestore变更日志），方便事后追溯异常行为

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