资源ID是RESTful URL中很重要的一个组成部分，大多数情况下这类资源ID都是用数字来表示的。这在不经意间泄露了业务信息，而这些信息可能正是竞争对手希望得到的数据。

　　以查看用户信息的RESTful URL为例：/users/100。由于用户ID是一个按序递增的数字，因此攻击者既可以通过ID知道目前应用中的用户规模，也可以分别在月初和月末的时候注册一个用户，并对比两个用户的ID即可知道当前这个月有多少新增用户。同理，如果订单号也是按序自增的数字，攻击者可以了解到一定时间范围内的订单量。

　　这类ID并不会给应用造成任何技术上的威胁，只是通过ID泄露出来的信息对于你的业务而言可能非常敏感。解决办法是不使用按序递增的数字作为ID，而是使用具有随机性、唯一性、不可预测性的值作为ID，atv直播，最常见的做法就是使用UUID。

　　返回多余的数据

　　前后端分离的情况下，两者之间通常以JSON作为数据传输的主体。有时候可能是为了方便前端代码处理，也可能是疏忽大意，总之后端API返回的JSON数据中包含了远远超出前端代码需要的数据，因此造成数据泄露。

　　例如，前端代码本意是请求订单信息，但是后端API返回的订单JSON数据中还包含了很多“有意思”的数据。

　　{ "id": 280010, "orderItems": [...], "user": { "id": 100, "password": "91B4E3E45B2465A4823BB5C03FF81B65" }, ... }

　　上面这个例子里，订单数据中包含了用户信息，最为关键的是连用户的密码字段也被包含在内。

　　解决办法显而易见，在给前端返回数据之前，将这些敏感的、前端并不需要的数据过滤掉。技术上实现起来易如反掌，但是真正难的地方在于让整个应用都严格的按照这样的方式来处理JSON数据，确保没有任何遗漏之处。

　　4. API缺乏速率限制的保护

　　先看一个例子。用户注册时发送短信验证码的API，由于没有做速率限制，使得攻击者可以用一段脚本不断的请求服务器发送短信验证码，导致在短时间内耗尽短信发送配额，或者造成短信网关拥挤等等后果。

　　受伤的不仅仅是发送短信的API，其他一些比较敏感的API如果缺乏请求速率限制的保护，同样也会遭遇安全问题。例如用户登录的API缺乏速率限制的话，攻击者可以利用其进行用户名密码暴力破解，再例如某些大量消耗服务器资源的API如果缺乏速率限制，攻击者可以利用其发起拒绝式攻击。

　　解决这类安全问题的原则就是对API请求的速率进行适当的限制。具体的做法有很多，最典型的例子就是使用图片验证码，其他的做法还有利用Redis的Expire特性对请求速率进行统计判断，甚至借助运维的力量（例如网络防火墙）来共同进行防御等等。

　　总结

　　开发出一个具备足够安全性的应用不是件容易的事情，本文中提到的只是RESTful架构风格下，众多安全问题中比较典型的一部分而已。之所以会有这些问题，其本质原因在于应用开发过程中，开发团队的注意力集中在业务功能的实现上，应用安全性相关的需求没有得到足够的明确和重视。

　　如果你不想被这些安全问题所困扰，建议通过在应用开发过程中引入威胁建模、在用户故事卡中设立安全验收标准、进行安全代码审查等一系列安全实践，尽可能从源头上规避这些问题。