灾难的根源： API 优先、安全最后策略
对 API 的需求日益增长。 无论是通过支持移动应用程序来推动数字经济，还是通过自动化和编排计划来提高内部生产力，API 无处不在。
许多组织都已采纳“API 优先！”的数字化口号。 也就是说，Cloud Elements 的2018 年 API 集成状况调查中的大多数 (60%) 受访者都向任何开发人员提供了 API。 它正在获得回报。 令人震惊的是，有 85% 的组织至少从 API 和 API 相关实施中获得了部分收入。 其中大部分 (59%) 为所在组织创造了 11% 至 50% 的收入。 超过十分之一 (11%) 的企业仅通过 API 就创造了超过一半的收入。 （ MuleSoft 的 API 价值不断提升）
但让我提醒你，他们向任何开发人员开放了他们的 API。 并非是任何善意的开发人员，而是任何开发人员。
当今 API 经济的开放性是导致 API 优先策略往往伴随着安全最后策略这一不幸现象的原因之一。
我们可以相对轻松地找到大量涉及知名组织的 API 相关安全事件。 无论是《福布斯》提到的，还是我们自己的 F5 实验室发现的，这些组织都遭受了与 API 相关的安全漏洞，而这些漏洞本可以通过完善的安全实践和工具来预防。
我们自己的 Ray Pompon（F5 实验室首席威胁研究推广员）在其 API 安全性研究中指出：
“……您可以看到与我们一直存在的应用安全中的相同、经典问题相关的模式：攻击者通过暴力攻击或窃取凭证获取访问权限。 此外，一旦通过 API 身份验证，攻击者就会利用过于宽泛的分配权限。”
来自< https://www.f5.com/labs/articles/threat-intelligence/reviewing-recent-api-security-incidents >
同样，经典的问题。 因为归根结底，API 通常被实现为携带 JSON 或 XML 数据负载的 HTTP 传输 URI。 这与携带 POST 表单数据有效负载的 HTTP 传输 URI 并没有什么区别。
我们不要忘记，API 仅仅是代码的接口。 根据WhiteHat应用安全统计数据，每 100K 行代码 (LOC) 平均有 39 个漏洞。 等等，这是针对传统应用的。如果你使用微服务架构实现接口（API），那么每 100K LOC 约有 180 个怎么样？ 无论如何，都存在很多漏洞。
API 与其对应方 Web 应用程序一样存在漏洞。这意味着它需要像 Web应用一样关注安全性。
然而，API 安全性的重视程度尚不及当今的 Web应用安全性——至少基于现有证据表明其所实施的安全测试方法并不完善。 SmartBear 的一项非正式民意调查发现，目前只有 12% 的受访者进行了“广泛的” API 安全测试。 几乎两倍——准确地说是 23%——根本没有进行 API 安全测试。 这与SmartBear 进行的更正式的研究一致，该研究发现 80% 的受访者测试了他们的 API。
但仍有 20% 的人没有这样做。
API-first 是参与数字经济并将业务和运营转变为精益、高效的数字机器的绝佳方式。 但将安全放在最后很容易让其成为 Twitter* 上流行的、尖锐的标签。 没有人希望这样。
因此，如果您要优先使用 API（您应该这样做），那么您需要将安全性作为头等公民。 不要为您的 API 接受安全最后的策略。
一些简单的步骤可以帮助您入门：
- 如果存在，就测试它。
- 如果有用户输入，请不要相信它。
- 如果有用户登录，请保护其免受暴力破解和撞库攻击攻击。
- 请注意维护和修补 API 所依赖的系统和服务的需要。 他们的弱点就是您的 API 的弱点。
在外面要注意安全。