如何在不每次变更都调用API的前提下，防止前端发送至Spring Boot后端的累加数值被客户端篡改？

首先得明确一个核心原则：永远不要信任客户端发送的任何原始数据——尤其是在你已经假设攻击者能完全控制浏览器（改JS、抓包、用DevTools）的前提下，客户端侧的任何加密、签名、混淆手段本质上都是可以被绕过的，你列出的几种方案的局限性已经充分说明了这点。

针对你的问题，结合约束条件，结论是：服务端追踪用户操作并维护权威数值，几乎是唯一真正安全的解决方案。不过我们可以先拆解为什么其他方案走不通，再讲服务端方案的具体思路，以及一些能提高攻击门槛的辅助手段。

为什么客户端侧的防御手段都不可靠？ #

你提到的几种方案的局限性其实都指向同一个问题：客户端环境是完全不可控的：

• HMAC签名：密钥存在浏览器里（不管是硬编码在JS还是动态获取），攻击者总能通过DevTools找到密钥，然后用伪造的数值重新生成合法签名。
• 非对称加密：攻击者可以直接修改JS代码，跳过加密步骤，或者把篡改后的数值重新加密发送。
• 哈希端点：既然是公开的，攻击者完全可以调用这个端点传入任意伪造数值，拿到有效的哈希值再发送给后端。
• 代码混淆：混淆只能增加读懂代码的难度，但攻击者根本不需要懂代码——直接抓包修改请求里的数值就行，完全绕开混淆的JS。
• 每次累加调用API：你已经明确说这个方案请求量太大不可接受，所以被排除。

服务端追踪的核心思路 #

既然客户端不可信，那权威的数值必须由服务端自己维护，客户端只需要传递“操作事件”，而不是最终的累加结果。具体可以这么做：

1. 客户端仅上报操作日志：比如用户完成了一次符合累加条件的操作，客户端不要自己累加数值，而是记录操作的类型、时间戳等信息（比如{"action": "click_button", "timestamp": 1699999999}），批量收集这些日志后发送给后端。
2. 服务端独立计算累加值：后端收到操作日志后，根据预设的规则（比如每个click_button操作加10），自己计算最终的累加数值。同时后端要对日志做合法性校验：
   • 校验时间戳是否合理（不能是未来时间，也不能早于用户会话的开始时间）
   • 校验操作频率是否符合正常用户行为（比如每分钟最多允许5次操作，防止攻击者批量伪造日志）
   • 校验日志的顺序性（防止攻击者打乱日志顺序或者重复提交）

如果客户端需要实时展示累加数值给用户，那客户端的数值只能作为本地缓存的展示值——比如客户端自己根据操作日志计算一个本地数值给用户看，但最终的权威数值必须以服务端计算的为准。

辅助防御手段：提高攻击门槛 #

虽然服务端追踪是核心，但你可以搭配一些手段来增加攻击者的攻击成本：

• 会话级密钥签名操作日志：后端给每个用户的会话分配一个临时密钥（存储在HttpOnly、Secure的Cookie里，JS无法读取），客户端在记录操作日志时，用这个密钥对日志内容+时间戳做HMAC签名，批量发送时带上签名。后端收到后用相同密钥验证签名，确保日志没有被篡改。
• 操作行为异常检测：后端可以统计用户的操作模式，比如突然出现远超正常频率的操作、操作时间间隔异常均匀（像脚本自动操作），就触发验证码验证或者暂时拒绝请求。
• 幂等性校验：给每个操作日志生成唯一的ID，后端记录已经处理过的日志ID，防止攻击者重复提交相同的日志来刷累加值。

总结 #

在你给定的约束条件下（必须批量发送、攻击者完全控制浏览器），服务端维护权威的操作状态和累加数值是唯一真正安全的方案。客户端侧的任何防御手段都只能作为辅助，无法彻底阻止攻击者篡改数据——因为只要客户端能接触到要发送的数值，就有办法修改它。

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