文章目录
在API安全发展的过程中，除了各大安全厂商和头部互联网企业在奔走呼吁之外，还有一家公益性安全组织，即开放式Web应用程序安全项目（Open Web Application Security Project，OWASP）。OWASP是一个开源的、非盈利的全球性安全组织，主要致力于应用软件的安全研究，它有很多开源项目，OWASP API安全Top 10就是其中的一个。
在OWASP API安全Top 10中，OWASP延续了Web安全的传统，收集了公开的与API安全事件有关的数据和漏洞猎人赏金平台的数据，由安全专家组进行分类，最终挑选出了十大API安全漏洞的类型，以警示业界提高对API安全问题的关注。这十大API安全漏洞类型的含义分别如下。
OWASP API安全Top 10的发布，第一次在公众视野中理清了API安全的常见问题类型，同时也从API生命周期管理、纵深防御的安全设计思想上，为API安全的综合治理提供了指导方向。当然，作为API安全的第一个版本，也会有它的不足，比如笔者认为API1与API5对问题成因的阐述，没有传统的Web安全中对水平越权、垂直越权的描述清晰，容易导致问题归类划分的混乱，但仍有理由相信，OWASP API安全Top 10对业界的重大意义，未来的版本发布更值得期待。
API1-失效的对象级授权
攻击者通过破坏对象级别授权的API，来获得未经授权的或敏感的数据，比如通过可预测订单ID值来查询所有订单信息。
【思考】我觉得这个问题能够排在第一位是很说明问题的，我觉得在大多数系统中可能都或多或少的存在该问题，比如对于一个访问用户详情的页面，一般API会设计成GET的请求方式，并且用户唯一标识会放在URL路径上，那么很大几率通过切换猜测的方式就可以去获取到某个人员的信息。
API2-失效的用户认证
开发者对API身份认证机制设计存在缺陷或无保护设计，导致身份认证机制无效，比如弱密码、无锁定机制而被暴露破解、Token未校验或Token泄露导致认证机制失效等。
【思考】比如对于任何的系统账号登录，至少需要在错误次数限制锁定的策略，依次保证系统不会被暴力破解登录。对于Token也是如此，Token的设计要尽可能的使用标准的安全策略，尽可能的不要自己去设计，要提高Token的破译难度。
API3-过度的数据暴露
在API响应报文中，未对应答数据做适当的过滤，返回过多的、不必要的敏感信息。比如查询用户信息接口时却返回了身份证号、密码信息；查询订单信息时也返回了付款银行卡号、付款人地址信息等。
【思考】对于前后端分离的场景，很多后端接口为了方便直接将ORM层返回的字段数据原样的返回给前端，这就导致了很多时候我们返回给前端的数据字段是远远超过前端所需要的，这不仅加大了网络传输包大小，同时也增加了数据泄露的风险。此外，在后端尽量不要仅仅将字段对应的值移除，而对应的字段返回，这样虽然不会直接泄露数据，但是暴露了字段的直接名称，这同样会增加安全隐患，攻击者获取到了更多系统表对应的信息，而且可以通过检索其他接口返回字段匹配的相同字段值名称，从而获取到他想要的数据，因此直接有效的方式就是前端需要那些字段，后端就提供那些字段。
API4-缺乏资源和速率控制
在API设计中，未对API做资源和速率限制或保护不足，导致被攻击。比如用户信息接口未做频次限制导致所有用户数据被盗；文本翻译接口没有速率限制导致大量文件上传耗尽翻译服务器资源。
API5-失效的功能级授权
与API1类似，只不过此处主要指功能级的控制，比如修改HTTP方法，从GET改成DELETE便能访问一些非授权的API；普通用户可以访问api/userinfo的调用，直接修改为api/admininfo，即可调用管理类API。
API6-批量分配
在API的业务对象或数据结构中，通常存在多个属性，攻击者通过篡改属性值的方式，达到攻击目的。比如通过设置user.is_admin和user.is_manager的值提升用户权限等级；假设某API的默认接口调用参数为{“user_name”:“user”，“is_admin”:0}，而恶意攻击者修改请求参数，提交值为{“user_name”:“attacker”，“is_admin”:1}，通过修改参数is_admin的值来提升为管理员权。
【思考】这里延伸一下，在程序设计中，重要的用户数据，用户权限，支付金额，用户密码，关键业务的日期时间比对等等，尽量不要存储在前端，或者说缓存在前端，但是在进行业务处理时获取的实际上必须是后端的数据，比如支付金额，前端可以保存值，但是实际支付的一定是后端根据识别用户从数据库拿到的，再者用户的权限也是后端识别用户所取得的，在进行一些秒杀限期等关于时间的处理中，也必须采用后端时间，对于页面倒计时等也需要不断轮询从后端获取，前端的传递数据是极大可能被篡改的。
API7-安全性配置错误
系统配置错误导致API的不安全，比如传输层没有使用TLS导致中间人劫持；异常堆栈信息未处理直接抛给调用端导致敏感信息泄露。
【思考】对于网络层来说，生产上基本都是HTTPS，其他的一般的项目也不需要过多的处理。对于异常堆栈信息这个在实际的开发中，就非常常见了，比如你访问一个Apache服务器发现错误，它会将Apache服务器信息、版本信息等直接返回，比如SpringBoot如果没有做处理的话，那么它会将错误信息的代码方法位置都展示出来，尤其对于堆栈信息中包含类似tomcat/apache版本信息，使用的依赖包版本信息，攻击者就可以通过观察版本，去漏洞库中检查对应组件的CVE等漏洞信息，从而实施攻击，这对于使用高版本组件影响较小，但是对于一些使用老版本或者过时组件影响很大。
API8-注入
与OWASP Web安全注入类型相似，主要指SQL注入、NoSQL注入、命令行注入、XML注入等。
API9-资产管理不当
对于API资产的管理不清，比如测试环境的、已过期的、低版本的、未升级补丁的、影子API等接口暴露，从管理上没有梳理清楚，导致被黑客攻击。
API10-日志记录和监控不足
对API缺失有效的监控和日志审计手段，导致被黑客攻击时缺少告警、提醒，未能及时阻断。比如没有统一的API网关、没有SEIM平台、没有接入Web应用防火墙等。