开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第16天，点击查看活动详情
为了有效地监视API的安全性，以下内容为需要采取的步骤。
部署功能齐全的 API 需要大量的开发时间用来质量保证和错误修复。大多数开发团队忽略的是部署后确保客户和公司数据所必需的安全和风险管理。在许多开发团队中，API 的安全性留给监控、日志记录和未来的渗透测试。不幸的是，这使得 API 容易受到攻击者的攻击，他们可以在你之前找到漏洞。“shift left”方法不是将安全留给部署后的策略，而是将安全扫描纳入当前的开发生命周期，并已证明在降低风险方面更为有效。
许多开发团队跳过关键的安全验证以加快代码部署
部署速度通常是企业 API 开发中的优先事项。虽然快速将功能部署到 API 很重要，但开发人员可能会为了速度而牺牲安全性，从而使端点容易受到常见攻击。对于使用面向公众的 API 处理和返回敏感数据的组织而言，这尤其危险。
由于开发人员通常会跳过重要的安全控制，因此跟踪和监控企业 API 的多个代码更改对 AppSec 和 DevOps 安全团队来说是一个挑战。渗透测试和漏洞扫描可能是 API 代码部署中的附加步骤，但手动执行安全验证通常会导致疏忽。与其依赖手动漏洞扫描，这甚至很难找到相关的代码更改，自动化对于帮助安全团队监控更改并自动发现潜在风险是必要的。
API 安全检查简要清单
要有效地监控 API 的安全性，需要采取必要的步骤并知道要在 API 代码中查找什么。以下是在部署 API 代码之前应采取的一些常见安全步骤：
- 审核和清点当前 API 存储库 ： 在设置自动扫描之前，必须知道开发人员将代码存储在哪里
- 将身份验证嵌入并集成到每个 API中 ： 始终将身份验证和授权嵌入到端点访问控制和数据管理中，以确保每个请求都得到验证。
- 验证所有输入 ： 应始终验证用户生成的输入，以确保 API 不易受到恶意代码注入的攻击。
- 实施最小权限原则 ： 最小特权原则是一种策略，将访问权限限制成员工执行日常工作功能绝对必要的数据。这包括对公共可访问数据的权限。
- 始终加密数据 ： 遍历公共互联网或内部的数据应使用加密安全密码进行加密，这意味着使用 TLS 1.2 版本或更高版本的密码套件。
- 对所有新 的API 进行代码审查 ： 安全团队应手动审查代码，以确保敏感数据不会暴露给错误或错误的业务逻辑。
- 对敏感 API 的渗透测试和扫描 ： API 代码的黑盒和白盒渗透测试有助于在攻击者之前发现安全漏洞。
- 限制端点调用的速率并使用会话管理 ： 为避免拒绝服务 (DoS) 或会话固定攻击，安全团队必须与开发人员合作实施控制，以管理可以对 API 进行调用的人员、时间和次数。
- 策略性地向互联网公开端点 ： 如果 API 不需要向互联网开放，则确定是否可以完全阻止它或公开部分端点以降低风险。
SAST(静态应用程序安全检测） 无法检测的常见漏洞
为了帮助阻止代码中的常见安全漏洞，许多组织实施了静态应用程序安全测试 (SAST) 工具。这些工具将在开发人员创建代码时扫描代码。当发现代码易受攻击时，它会向开发人员显示警告并说明如何修复它。虽然这些工具也有其优势，但它们无法解决糟糕的业务逻辑问题，这些业务逻辑可能会使应用程序面临不易检测的漏洞。SAST 工具发现编码错误但缺乏上下文，这对于组织花费大量开发和应用程序安全工程师工时的优先级排序过程至关重要。未考虑的复杂业务逻辑可能会使应用程序面临未发现的漏洞。
SAST 面临的最大挑战是上下文。本地 API 与无服务器云原生功能不同。事实上，云原生和云托管应用程序通常配置错误，SAST 无法检测到这些漏洞。WAF 也无法发现云错误配置，而这些问题已成为大型数据泄露的原因。
云配置错误可能包括设计不当的身份验证和允许任何人读取敏感数据的授权控制基础设施设置，缺少可用于捕获持续攻击的监控和日志记录等等。你可以在编写应用程序时运行 SAST，但它不会在部署之前捕获任何这些问题。WAF 也不会捕获这些问题，这意味着要么对云配置亲自审查，要么聘请第三方在未来审查配置。
另一个常见问题是将第三方库和软件开发工具包导入到代码库中。这些库可能有故意的漏洞，或者它们可能在第三方开发人员不知情的情况下被破坏。还必须扫描这些工具，并监控所有开发人员的安全公告以获取最新的安全补丁。补丁必须尽快安装。
