随着restful的流行，现在微服务以及很多api相关应用都采用这种架构风格进行设计。
好处显而易见，但是还是要注意其伴随的安全问题
1.遗漏了对资源从属关系的检查
例如：/users/10
有没有验证当前登陆的是否是id为10的用户？如果填的是其它id是否能够获得数据？
当包含多个资源的时候，例如：/users/10/orders/10
是否对用户以及订单都进行过验证？
2. HTTP响应中缺失必要的 Security Headers
X-Frame-Options
为了防止应用遭受点击劫持攻击，可以使用X-Frame-Options: DENY明确告知浏览器，不要把当前HTTP响应中的内容在HTML Frame中显示出来。
X-Content-Type-Options
在浏览器收到HTTP响应内容时，它会尝试按照自己的规则去推断响应内容的类型，并根据推断结果执行后续操作，而这可能造成安全问题。例如，一个包含恶意JavaScript代码的HTTP响应内容，虽然其Content-Type为image/png，但是浏览器推断出这是一段脚本并且会执行它。
X-Content-Type-Options就是专门用来解决这个问题的Header。通过将其设置为X-Content-Type-Options: nosniff，浏览器将不再自作主张的推断HTTP响应内容的类型，而是严格按照响应中Content-Type所指定的类型来解析响应内容。
X-XSS-Protection
避免应用出现跨站脚本漏洞（Cross-Site Scripting，简称XSS）的最佳办法是对输出数据进行正确的编码，不过除此之外，现如今的浏览器也自带了防御XSS的能力。
要开启浏览器的防XSS功能，只需要在HTTP响应中加上这个Header：X-XSS-Protection: 1; mode=block。其中，数字1代表开启浏览器的XSS防御功能，mode=block是告诉浏览器，如果发现有XSS攻击，则直接屏蔽掉当前即将渲染的内容。
Strict-Transport-Security
使用TLS可以保护数据在传输过程中的安全，而在HTTP响应中添加上Strict-Transport-Security这个Header，可以告知浏览器直接发起HTTPS请求，而不再像往常那样，先发送明文的HTTP请求，得到服务器跳转指令后再发送后续的HTTPS请求。并且，一旦浏览器接收到这个Header，那么当它发现数据传输通道不安全的时候，它会直接拒绝进行任何的数据传输，不再允许用户继续通过不安全的传输通道传输数据，以避免信息泄露。
3.不经意间泄露的业务信息
比如：/users/10000
是否客户就知道当前应用中至少有1w个用户，根据自己的注册时间等信息推测出用户的大概数据？
在电商网站中，是否可以通过/orders/1000,或者订单号180504455632056推测出销售信息？
还有就是接口返回多余的数据。
开发在写接口的时候为了省事，直接select * from users把用户的所有数据都返回过来。
4.API缺乏速率限制的保护
用户注册时发送短信验证码的API，由于没有做速率限制，使得攻击者可以用一段脚本不断的请求服务器发送短信验证码，导致在短时间内耗尽短信发送配额，或者造成短信网关拥挤等等后果。
例如用户登录的API缺乏速率限制的话，攻击者可以利用其进行用户名密码暴力破解，再例如某些大量消耗服务器资源的API如果缺乏速率限制，攻击者可以利用其发起拒绝式攻击。
解决这类安全问题的原则就是对API请求的速率进行适当的限制。具体的做法有很多，最典型的例子就是使用图片验证码，其他的做法还有利用Redis的Expire特性对请求速率进行统计判断，甚至借助运维的力量（例如网络防火墙）来共同进行防御等等。