如今，API 已成为将当今APP经济的粘合剂，在Web 2.0的浪潮到来之前，开放的API 甚至源代码主要体现在桌面应用上，越来越多的Web应用面向开发者开放了API，同时也正在成为黑客攻击的头号目标。
API的运行方式与URL的运行方式大致相同，用户使用Web搜索时，页面展示结果是动态的，以手机银行应用程序为例，API也以类似的方式运行，它可以获取用户的地理位置、姓名、账号和账户余额，并相应地填充交互页面中的字段，但因为API包括所有安全检查，并且通常直接与后端服务通信，所以也更容易被攻击者青睐。

以下三类最常见的API漏洞：

第一：资产管理不当

此API缺陷是环境隔离和管理不足的结果，允许攻击者访问安全性不足的API端点，在之前的网络安全事件中，就有由于开发人员API无需编辑即可访问生产数据，进而暴露了客户的系统，属于此类别的漏洞还包括未监控开发API中的敏感数据，以及让已弃用的API仍处于在线或公开状态。

第二：受损的对象级别授权Broken Object Level Authorization (BOLA)

BOLA的通俗定义是对对象访问请求的验证不充分，它允许攻击者通过重用访问令牌来执行未经授权的操作。Peloton事件是最近诸多BOLA利用中比较有名的一个案例，攻击者可以查看包括标有私人事件在内的，几乎所有用户的个人资料。此类攻击可能影响到从开发到运营，再到营销和公共关系的每个业务组。

第三：无效的用户身份验证

1.图形验证码：

将图形校验码和手机验证码进行绑定，在用户输入手机号码以后，需要输入图形校验码成功后才可以触发短信验证，这样能比较有效的防止恶意攻击。目前大部分应用都是采用这种方式。

2.限定请求次数：
在服务器端限定同一IP地址，同一设备，同时间范围内的接口请求次数。比如同一号码重复发送的时间间隔,一般为60或120秒；设置每个IP每天最大的发送量；设置单个手机号每天的最大发送量。

3.流程条件限定：
将手机短信验证放在最后进行，比如需要用户必须注册后，或者用不必须填写了某些条件才能进行短信验证。

4.归属地是否一致：
服务器端检查用户的IP所在地与手机号归属地是否匹配，如果不匹配则提示用户手动操作等。

5.服务器接口验证：

当用户登录成功后，返回一个由Token签名生成的秘钥信息(Token可使用base64编码和md5加密，可以放在请求的Header中)，然后对每次后续请求进行Token的封装生成，服务器端在验证是否一致来判断请求是否通过。

（1）常规的方法：用户登陆后生成token，返回客户端，然后服务器使用AOP拦截controller方法，校验token的有效性，每次token是一样的;
（2）用户登录后生成临时token，存到服务器，并返回客户端，客户端下次请求时把此token传到服务器，验证token是否有效，有效就登陆成功，并生成新的token返回给客户端，让客户端在下一次请求的时候再传回进行判断，如此重复。 这种方法有性能问题，但也有一个漏洞，如果用户在一次请求后，还未进行下一次请求就已被黑客拦截到登录信息并进行假冒登录，他一样可以登录成功并使用户强制下线，但这种方法已大大减少被假冒登录的机会。

（3）两层token：一般第一次用账号密码登录服务器会返回两个token，时效长短不一样，短的时效过了之后，发送时效长的token重新获取一个短时效，如果都过期，那么就需要重新登录了。当然更复杂你还可以做三层token，按照业务分不同token。

6.采用https：
线上的api接口开启https访问,这样做的话别人抓包的难度会提高很多，而且https需要秘钥交换，可以在一定程度上鉴别是否为伪造的网络非真人IP地址。

7.服务器端代理请求：
针对于网站，这也是解决跨域的方案之一，采用服务器代理可以有效的防止接口真实地址的暴露。

网络安全举足重要，近几年API安全事件也层出不穷，所以，无论是企业用户还是个人用户，一定要了解API存在的漏洞以及相关的风险，便于最及时的做好安全防护！