安全兜底分级：
- 无限额涉及钱
比如退款 - 限额涉及钱
为用户提供的红包奖励等，通常限额 - 无门槛虚拟货币
无门槛优惠券、积分等，由于这部分基本与货币可以等值，但是由于存在可以追回的机会，所以尚存一些容错） - 有门槛虚拟货币
因为是为了促销，并不会带来实质经济损失，所以没有那么敏感
分级之后，再进一步划分处理的级别。因为人力和时间都是有限的，很难将所有的安全兜底都控制的那么完美，那就优先保证一些损失影响可能较大的业务上。
权重更高的业务，可以予以更严谨的测试，以及附加的人工审核机制，更频繁的监控等。相对权重较低的，就可能重视程度不那么高，仅保留较低限度的兜底。
安全第一步
1 防刷
最常见的短信验证码服务，由于是注册用，所以无需登录就能调用。若发短信接口无任何保护措施，直接调用三方短信通道，很容易被短信轰炸平台滥用。
如何防刷？
验证额外参数信息
验证客户端请求头的一些额外参数，比如是否存在浏览器或手机型号、设备分辨率请求头。因为像那些爬虫，一般就只能接收到URL。
先过注册页
无论何种客户端注册，一定要先进入注册页，才能看到验证码按钮。
所以可以在页面打开时请求固定的前置接口，为这个设备开启允许发送验证码的窗口，之后的请求发送验证码才算合法请求。
这可以拦截绕过固定流程，直接通过接口调用验证码的请求。
控制同一手机号的发送次数、间隔
除非是没收到短信，否则用户不太会请求了验证码后不点击注册，还重新请求。
所以，可以限制同一手机号每天的最大请求次数。还要控制好发送的时间间隔，常见的至少间隔1min。
增加前置操作
短信轰炸平台会收集很多免费短信接口，而且一个接口它们也只会给一个用户发一次短信，不会触发上一条规则。
对于这种情况，可以将图形验证码作为前置条件。技术🐂🍺的还可使用滑块、验证码文字点击、人机检测。
2 限量
对优惠券这种虚拟资产，平台方必须确保其使用界限。
对于商家，可能只是收到一个用户支付的订单，并不知道用户使用了平台的优惠券。
大部分平台和商家都是事后对账结算，所以下单了就会马上安排发货，事后造成大量资金损失。大量跟风网络主播被薅羊毛的店铺就是这么没的。
优惠券应该需要提前申请：用于何种活动、谁申请的。
幂等
考虑如下：
- 幂等依据
每次交互生成的token、客户端的序列号、有意义的业务订单号等 - 根据幂等依据进行幂等处理：
- 限制：比如锁、状态机控制
- 去重
先有订单，再操作资金。任何资金操作都要在平台侧生成业务属性订单，可以是优惠券发放订单，可以是返现订单，也可以是借款订单。
订单的产生必须要有业务属性：
比如，返现发放订单必须关联到原先的商品订单、借款订单必须关联到那个借款合同。
幂等处理必须是全链路的，从开始到最后都贯穿使用相同业务订单号，才能实现最终的支付幂等。
支付操作一般是调用三方支付接口。这些接口都会有商户订单号，相同商户订单号不会重复处理，所以三方公司的接口可实现唯一订单号的幂等。
防刷、幂等其实都是事前手段，若系统正被攻击或利用，如何发现问题？
监控是较好的手段，难点是报警阈值的设置，可以对比昨天同时，上周同时的量，发现差异达到百分比阈值就报警。此外，对于活动可以申请单独的活动监控标签，单独呈现曲线，做好量的预估，超量报警，有的时候大盘很大的话活动给整个大盘带来的变化不明显。
可通过监控实现类似熔断机制，比如数据监控某个功能在被刷，触发报警，同时熔断，暂时把该功能禁掉，减少损失。
任何第三方资源的使用一般都会定期对账，若对账发现：
我方系统记录的调用量 < 对方系统记录的使用量
一般因为啥呢？
- 可能是在一个事务内调用外部接口，调用超时后事务回滚，导致本地就没有保存数据
- 我方系统对于第三方调用返回值处理不当，导致有重复调用，即幂等没做好
推荐所有第三方服务的交互，将request和response完整记录到数据库。
