【问题标题】:Is it a good practice to publicly document an open API? [closed]公开记录开放 API 是一种好习惯吗? [关闭]
【发布时间】:2019-06-04 00:15:28
【问题描述】:

每个人都可以肯定开放 API 的优缺点。

但是,公开记录开放 API(要求对其请求进行身份验证)是好还是坏的做法?

我所说的公开文档是指创建一个文档,显示 API 可以接收的请求正文的结构,并提供所有这些字段的描述。

例如,给定一个端点my-public.url/myendpoint/myresource,有可用的PUTPOSTDELETEGET http 请求,有一个静态页面my-public.url/document/myendpoint,它显示了所有可接受的http 请求以及对执行请求所需的标头和请求正文。

一方面,这将有助于外部开发人员轻松使用 API,但另一方面,如果有人以某种方式获得访问权限,他们很容易发出请求并破坏系统,因为整个结构给出了 API。

【问题讨论】:

  • API 密钥、令牌等呢?
  • 这些肯定是保密的,并且在使用和容纳 API 的各方之间进行通信

标签: rest api http security web


【解决方案1】:

您可以从风险的角度来看待这一点。为 API 提供公共文档存在风险,出于您提到的原因,它可能会帮助攻击者。另一方面,安全性始终是一种平衡,提供文档对您的用户有帮助(甚至是必要的)。

此外,您不应该通过默默无闻来实现安全性,即。攻击者应该知道事情是如何工作的 - 但事实上很多时候情况并非如此。

由于提供公共文档是一种风险,因此您必须以某种方式对其进行处理。你可以做几件有风险的事情,例如你可以接受它(~什么都不做)、消除它(~在这种情况下不提供文档)或减轻它。

降低此风险意味着您需要采取其他措施来降低利用的可能性或降低影响。例如,可以通过加强对软件开发方式的控制、围绕身份验证和授权功能添加自动化测试、添加静态代码分析器等来降低可能性。可以通过分离逻辑层的良好架构、入侵检测/预防系统,甚至选择单租户而不是多租户来减少影响。

归根结底,这一切都归结为您想接受什么风险,而这完全取决于您。有了适当的控制,就可以提供公共文档——你还能指望用户如何使用你的 api?问题是什么是“适当的”控制,这取决于您的风险偏好。

【讨论】:

    【解决方案2】:

    您的应用程序 API 中的风险根本没有因为公开记录而增加。

    想到这里,我想到了一些原因,

    • 如果您使用的是基于浏览器的客户端,只要稍有了解浏览器开发者工具的 NETWORK 选项卡的人都可以找到您的 API 详细信息。
    • 如果有任何移动客户端使用您的API,可以使用WireShark 等应用程序轻松查看请求信息。最著名的 API 测试器应用程序POSTMAN 也支持这样的功能。

    借助上述工具,任何人都更有可能了解您的 API 详细信息。

    公共文档的优点

    • API 消费者可以直接访问您的公共 API 文档,这明显节省了 API 开发者与消费者沟通的大量人力时间。 (基于版本的 API(和文档)在更改现有 API 时非常有用)
    • 创建像 Postman Collections 这样的 API 演示/测试工具包将有助于 API 使用者轻松测试和使用 API。

    您可以注意以下几点以降低您的应用程序中的风险。

    • 身份验证 - 登录凭据/访问令牌/API 密钥
    • 授权 - 对正在访问/修改的任何资源进行访问检查。
    • API 速率限制 - 避免 DOS 攻击。

    【讨论】:

    • 这个答案是完全错误的,与已知的安全最佳实践相反。虽然公共文档当然有优势,但正如我在下面的回答中所描述的那样,这确实是一种风险。这并不意味着公共文档是错误的,一点也不,但它绝对人们必须考虑和管理的风险。
    • IMO,保护您的 API 是必须要做的,从这个角度来看,我回答了这个问题。问题还说api需要适当的身份验证,这意味着开发人员正在尝试解决风险因素。因此,最好通过避免文档来避免权衡风险您的应用程序。处理安全很重要。
    猜你喜欢
    • 2014-07-01
    • 2013-03-30
    • 2012-08-11
    • 2015-02-18
    • 2016-03-20
    • 1970-01-01
    • 2020-08-25
    • 2013-12-31
    • 2020-05-09
    相关资源
    最近更新 更多