如何防止用户篡改数据

所以要在后端验证啊，你前端验证只是保证用户体验用的

你是 web 应用还是 app 啊？ app 的话可以接口加签名。

不考虑用户体验的话，加个滑块验证，像抢红包一样

如果这个接口是前端可以直接调用的话，那么答案就是无法保证这条记录的可信度。除非这个动作只能在服务端发起并完成，譬如我在网关上根据用户调用接口的行为，在日志中记录其请求参数，这种数据就是可信的。

数据记录的可信度，可以在插入操作前对用户输入的数据进行检查，比如是否有不符合插入数据规定外的敏感危险字符？做好数据的过滤，规定好插入数据的格式，不符合的禁止插入，或者设置一些正则表达式，对敏感字符进行替换处理~另外，从你的业务场景里可以看出，如何防止登入的用户直接手动调用？这个可能就涉及到用户登入系统后，插入数据的接口可能会暴露，可以适当对调用此接口的用户做些鉴权，也要防止越权，不过最关键的个人认为还是对传入数据的过滤处理~

如果是用户能操作的值，那防不了
如果是不能操作的值，你自己就能判断出来

为什么插入日志这种动作要在前端发起接口来实现，不是应该处理完主业务之后再执行插入日志操作吗。和前端唯一的互动就是点击按钮调用接口那一下。

后端判断用户此次操作的合法性，如果是购买商品操作，可能不是用户 post 一个请求你就给他发货吧。
具体如何判断操作合法性，看你的具体场景。

感觉这两种操作没区别，都是合理操作，防是个伪命题

你看目前大型网站哪家能防趴？

签名+时间戳，能解决大部分人，真正的高手防不住

@renfei #11 web 软件，不是 app ，签名是指什么。 时间戳的话具体怎么操作

我凭空想到的一个方法是通过一个动态秘钥来交互，每次发给后端需要后端校验是否符合，用过一次的秘钥不能再使用

@unt web 端，我可以看到你的代码，我模仿你的逻辑，先调用动态密钥接口获取一个，拿到这个密钥再调用下一个接口，不就行了。
时间戳可以防止请求被拦截重放，签名可以验证是否被篡改，只会皮毛的脚本小朋友就会放弃，大佬的话你还是拦不住的
任何软件都能破解，只是代价不同，只要够让大部分人放弃就行了，收益比代价大的时候，就会放弃破解

@renfei #14 动态秘钥不是调接口获取的。类似双因素认证，只不过我想的是一个秘钥集合

@unt 你标题是防止用户自己篡改，双因素的验证码，也在用户自己手里，你怎么觉得能区分用户给你 post 真的数据还是假的数据呢

所以才会有谷歌的：
" I'M NOT A ROBOT "

@unt #13 这就是最简单的 CSRF Token ，可以防部分，但懂的人自己做浏览器自动化肯定能模拟出来

前端只是 UI ，业务逻辑在后端，你肯定要在后端验证合法性啊

没表述清楚，让人不想答。答了的都是猜的需求。