防止接口被人恶意调用，有哪些可靠地方式？

如果是面向 app 的话，客户端对参数签名，服务端校验

对内的接口，ip 白名单；对外的接口权限、流量控制

@mooczz 对参数签名的方法感觉同样有可能被破解。

oauth2

用户量小且没有用户校验的话，直接 ip ban 掉，简单粗暴

@582033 OAuth2 只是授权，如果谁都能注册呢

@springmarker 想象成一个注册就能用的 APP，黑名单肯定 ban 不完所有代理啊

@panpanpan #7 你得增加注册成本
恶意调用不可能完全禁止的
你得提高别人恶意调用的成本，当『他的调用成本』大于『调用你获取的利益』时，他肯定不会再干了啊

如果是还没上线，那好办，接口里面一定要通过某种方式传递一些设备信息（例如 IMEI 等）来识别身份；并且要保留验证码机制，根据该设备的请求情况决定是否在关键步骤中开启验证码模式。

如果是已经上线，但只能取到 IP，那可以根据 IP 维度对用户的请求进行监控，例如连续多次访问敏感接口（发送验证码之类的）则可以考虑对这个 IP 进行降权处理，访问某些接口的时候被 ban 掉。

------------------------------------------------------------------------------

上面可能需要利用到的技术就是复杂验证码、Nginx 动态编程。Nginx 动态编程可以考虑 OpenResty

@panpanpan

如果是 Android 的海外业务，play 渠道的可以考虑 safetyNet Attestation API

General 的则可以考虑类似反爬虫的策略（简单些的类似 geektest 的 captcha ），毒性越高限制越多。
app 可以拉 app 包的签名(基本都在用，比如 xx 地图的公开 API)

@odirus
哎，又是一个要 IMEI 的

app 用内部封一个 key+用户密码组合成新的 key 的方法验证，发现内部 key 有恶意访问，就下发新 key 给 app 并且淘汰旧的 key。这样 app 这边就能做到可控。

注册这块增加注册成本，国内最简单的方案就是绑个手机号。国外没研究过但是绑个 google 市场 id 应该也是不错的选择。

公司等第三方大规模调用也是一样，两套 key，发现恶意通知对方换 key，发现多次恶意通知对方整改。

制度上解决比较靠谱，技术上别说自动化，你就是雇佣上几个维护人员 7*24 的根据监控数据调整接口访问，也不一定能解决别人上爬虫。

@honeycomb

没什么大惊小怪的，其他方案也有的是

如果只有存储权限，也可以不用 IMEI 的，只要能确定用户身份即可，之前我们做法是在应用存储区域写一个随机字符串文件，如果存在则在请求的时候发送这个；如果不存在，则生成后再携带发送。

----------------------------------------------------------------------------------------------

不过既然人家都能破解了，，肯定直接替换接口里面的参数，这个时候就可以根据请求请求对 IP 和 deviceID 进行评分，低于某个评分的情况就直接 ban 掉。

@odirus 这种思路跟要求登录然后通过用户信息来识别有些类似，通过大量的日志分析确实可以识别到一些异常用户，可以 ban 掉那些大量请求的，但是从原理上面来说这些信息依然是可以伪造的，所以。。。

@xomix 如何监测 key 有没有被恶意使用我感觉也是问题的关键呢

api 限制速率

@panpanpan

一定要根据自身 APP 的特点哈，我做了一些规则来对设备进行分数评价（这些规则只要不泄露，写爬虫的人肯定不知道），例如：

1 ）调用注册之前一定会调用拉取过首页广告的接口
2 ）一个 IP + deviceId 只会在 60s 内至多调用一次验证码发送接口
3 ）以及更多的特定应用规则

基本原理就是说系统会根据设备的访问历史记录，对请求进行动态评分，并且在 Nginx 这一层 "恶搞" 分数特别低的一些爬虫，甚至是 ban 掉。

如果有哪些 IP + deviceId 违反了上面的规则，我就会对这台设备进行扣分，当分数低于某个阈值的时候，会通过 OpenResty 直接返回相应的错误，而不是转发到后端程序。

@gouchaoer @odirus Got it.
用户量大了之后这确实是一些很不错的防爬虫手段。但是我最初提问的初衷其实是如何防止别人拦截请求，然后来模拟请求。哈哈

@panpanpan 上谷歌验证码

App 或者网页都可以做一些用户行为手机分析，很多软件都干这事。
比如我要注册，那肯定要点击输入框，然后 balabalabala 账号，balabala 密码，然后点击注册，这里屏幕触摸很多，网页的话还能进行捕捉键盘，所有用户输入都能捕捉到，然后收集压缩加密发给服务器进行分析，就知道是真人还是假的人了。理论上还是可以破解，但是破解成本挺大的

HTTPS ?

@sculley HTTPS 只能防止传输过程中有人劫持修改，不能防止模拟请求

@odirus

“在应用存储区域写一个随机字符串文件，如果存在则在请求的时候发送这个；如果不存在，则生成后再携带发送。 ”
这样用 UUID/InstanceID 的做法比较能接受，但是如果要获取设备持久不可更改的识别码，一般来说，除去少量服务外是不能接受的。应用只能在一次安装到卸载为止的生命周期中识别特定设备。


“如果有哪些 IP + deviceId 违反了上面的规则，我就会对这台设备进行扣分”
挺好的做法

跟百度的 API 一样免费的有次数限制

HMAC 算法

阿里的 API 网关好像是后端加密之后放进 header 里面做一个转发。

@panpanpan 根据 key 和用户写日志啊，突发服务器资源吃紧的时候日志一目了然