每个人都可以确定开放 API 的好处和缺点。
但是,公开记录开放 API(要求对其请求进行身份验证)是好事还是坏事?
我所说的公开文档是指创建一个文档,显示 API 可以接收的请求正文的结构,并提供所有这些字段的描述。
例如,给定一个端点my-public.url/myendpoint/myresource
,可用PUT
、POST
、DELETE
和 GET
http 请求有一个静态页面 my-public.url/document/myendpoint
显示所有可接受的 http 请求以及 header 和正文的描述执行它所需的请求。
一方面,这将有助于外部开发人员轻松使用 API,但另一方面,如果有人以某种方式获得访问权限,他们将很容易发出请求并破坏系统,因为整个结构给出了API。
您可以从风险的角度来看待这个问题。为 API 提供公共(public)文档存在风险,出于您提到的原因,它可能会帮助攻击者。另一方面,安全始终是一种平衡,提供文档有助于(甚至是必要的)您的用户。
此外,您不应该通过默默无闻的方式实现安全性,即。事情是如何工作的应该被认为是攻击者已知的 - 但很多时候事实并非如此。
由于提供公共(public)文档存在风险,因此您必须以某种方式对待它。您可以做几件有风险的事情,例如您可以接受它(~什么都不做)、消除它(~在这种情况下不提供文档)或减轻它。
降低这种风险意味着您需要采取更多措施来降低利用漏洞的可能性或降低影响。例如,可以通过加强对软件开发方式的控制、围绕身份验证和授权功能添加自动化测试、向组合中添加静态代码分析器等来降低可能性。可以通过分离逻辑层、入侵检测/预防系统甚至单租户而不是 Multi-Tenancy 的良好架构来减少影响。
最终,一切都取决于您愿意接受什么样的风险,而这完全取决于您。通过适当的控制,提供公共(public)文档是可以的——否则你怎么能期望用户能够使用你的 api?问题是什么是“适当的”控制,这取决于您的风险偏好。