需立即实施的API安全措施

吕蕴藉

应用程序接口（API）形成应用程序之间的桥梁，使程序能够跨不同的代码库和硬件相互通信，但在居心不良的人的手中，API可能会造成潜在的巨大损害。

企业应尽快实施以下策略，来应对更严峻的API安全态势。

为未来的用户而不是现在的用户构建

当API处于起步阶段时，它们通常旨在满足一小部分开发人员一起工作的需求。这些开发人员彼此认识，甚至可能共享一个办公空间，并且可能觉得几乎不需要实施身份验证协议来确定他们的身份。他们为什么要这样做？不久之后，一个特别有用的API从团队中脱颖而出，它进入了比最初预期更广泛的用户网络中。适当的安全措施应该在漏洞出来之前就部署到位，而不是在很久之后。

限制用户

说到未来的用户，如果可能的话，可以为更多的用户做计划，但控制得更少。在严格需要了解的基础上授权访问，更多的用户意味着更大的网络攻击面，尤其是在权限没有明确和彻底定义的情况下。

限制数据

Equifax公司数据泄露事件让人们感到担忧，因为该公司保存了近1.5亿美国人的私人财务信息。幸运的是，并非每家公司的商业模式都需要收集社会安全号码、驾照、地址等信息。严格定制数据收集，以便只需要最必要的数据，而未收集的数据也要受到保护。

加密数据

确保通信路径使用适当的加密协议，例如SSL或TLS。同样，静态数据也应该加密，这是显而易见的，但由于帐户和密码以纯文本形式存储，因此经常发生数据泄露。可见，仅加密是不够的，它还必须被正确使用。某些协议（例如TLS）允许在服务器或客户端禁用加密验证，从而导致互联网流量被拦截的潜在风险。企业需要確保API符合最新的安全最佳实践，以确保通信安全可靠。

制定分页限制

如果没有适当的API分页，服务器查询可能会返回一个结果或大量的结果。后一种情况会迅速消耗系统资源并使应用程序停止。更糟糕的是，它不需要恶意行为者造成伤害———无辜的用户可能会过于松散地构建查询，并收到惊人的响应。幸运的是，分页很容易实现，最简单的形式是偏移分页，它为用户提供了一个可以检索的预定义记录窗口。其他形式的分页包括keyset和seek，它们各有优缺点。

在SQL查询中使用准备好的语句

SQL代码注入是非常普遍的攻击，使网络攻击者能够冒充其他用户、破坏数据库或窃取数据。正如其名称所暗示的那样，网络攻击者将SQL代码偷偷带入数据库查询中，通常是利用正确配置的服务器应该过滤掉的转义字符。准备好的语句通过使用只能存储特定值而不是SQL片段的占位符来阻止攻击者注入SQL代码的能力。另一种防止SQL注入的方法是确保数据输入符合预期，例如，电话号码应该注册为整数并且不包含字符串；名称应包含字母，但不能包含数字。

加强最终用户和应用程序认证

对于访问应用程序的用户，根据最新的安全最佳实践实施例行密码重置策略。对于与API交互的应用程序本身，为应用程序的每个版本使用唯一的凭据，从而更容易根除过时的版本。

实施利率限制

当网络攻击者向服务器发送大量登录凭据以通过纯粹的机会成功匹配时，就会发生暴力攻击。基本速率限制可以阻止这些攻击，方法是防止在合理的时间范围内发生多个查询。一个人能在一分钟内输入几百次密码吗？可能不会。那么，为什么API要接受如此高的数字呢？

安全是管理风险的艺术，而不是消除风险。没有堡垒是坚不可摧的，但网络攻击者往往会沿着阻力最小的路径移动，并以安全标准差的受害者为目标。而企业需要提高API安全性，并避免成为网络攻击者的目标。