选择所需的最低权限
注册 GitHub 应用时，请选择 GitHub 应用所需的最低权限。如果应用的任何密钥或令牌遭到泄露，这将限制可能造成的损害。有关如何选择权限的更多信息，请参阅“为 GitHub 应用选择权限”。
当您的 GitHub 应用创建安装访问令牌或用户访问令牌时，您可以进一步限制应用可以访问的仓库以及令牌具有的权限。更多信息，请参阅“为 GitHub 应用生成安装访问令牌”和“为 GitHub 应用生成用户访问令牌”。
保持在速率限制内
订阅 Webhook 事件，而不是轮询 API 以获取数据。这将有助于您的 GitHub 应用保持在 API 速率限制内。更多信息，请参阅“将 Webhook 与 GitHub 应用一起使用”和“构建响应 Webhook 事件的 GitHub 应用”。
考虑使用条件请求来帮助您保持在速率限制内。有关条件请求的更多信息，请参阅“使用 REST API 的最佳实践”。
如果可能，请考虑使用整合的 GraphQL 查询代替 REST API 请求，以帮助您保持在速率限制内。更多信息，请参阅“比较 GitHub 的 REST API 和 GraphQL API”和“GitHub GraphQL API 文档”。
如果您确实达到了速率限制并且需要重试 API 请求，请使用x-ratelimit-reset或Retry-After响应头。如果这些头不可用，请在重试之间等待指数递增的时间量，并在特定次数的重试后抛出错误。更多信息，请参阅“使用 REST API 的最佳实践”。
保护您的应用凭据
您可以为您的 GitHub 应用生成私钥和客户端密钥。使用这些凭据，您的应用可以生成安装访问令牌、用户访问令牌和刷新令牌。这些令牌可用于代表应用安装或用户发出 API 请求。
您必须安全地存储这些凭据。存储机制取决于您的集成架构及其运行的平台。一般来说，您应该使用旨在在您使用的平台上存储敏感数据的存储机制。
私钥
您的 GitHub 应用的私钥授予对安装了该应用的每个帐户的访问权限。
考虑将您的 GitHub 应用的私钥存储在密钥保管库中，例如Azure Key Vault，并使其仅用于签名。
或者，您可以将密钥存储为环境变量。但是，这不如将密钥存储在密钥保管库中安全。如果攻击者访问环境，他们可以读取私钥并获得对 GitHub 应用的持久身份验证。
您决不应该在应用中硬编码您的私钥，即使您的代码存储在私有存储库中也是如此。如果您的应用是原生客户端、客户端应用或运行在用户设备上（而不是运行在您的服务器上），您决不应该将私钥与您的应用一起发布。
您不应该生成超过所需数量的私钥。您应该删除不再需要的私钥。更多信息，请参阅“管理 GitHub 应用的私钥”。
客户端密钥
客户端密钥用于为您的应用生成用户访问令牌，除非您的应用使用设备流程。更多信息，请参阅“为 GitHub 应用生成用户访问令牌”。
如果您的应用是网站或 Web 应用，请考虑将您的客户端密钥存储在密钥保管库中，例如Azure Key Vault，或者作为服务器上的加密环境变量或密钥。
如果您的应用是原生客户端、客户端应用或运行在用户设备上（而不是运行在您的服务器上），则无法保护您的客户端密钥。如果您计划根据您的应用生成的令牌来控制对您自己服务的访问，则应谨慎行事，因为任何人都可以访问客户端密钥来生成令牌。
安装访问令牌、用户访问令牌和刷新令牌
安装访问令牌用于代表应用安装发出 API 请求。用户访问令牌用于代表用户发出 API 请求。刷新令牌用于重新生成用户访问令牌。您的应用可以使用其私钥生成安装访问令牌。您的应用可以使用其客户端密钥生成用户访问令牌和刷新令牌。
如果您的应用是网站或 Web 应用，您应该在后端加密令牌，并确保访问令牌的系统具有安全性。考虑将刷新令牌存储在与活动访问令牌不同的位置。
如果您的应用是原生客户端、客户端应用或运行在用户设备上（而不是运行在您的服务器上），您可能无法像在服务器上运行的应用那样安全地保护令牌。您不应该生成安装访问令牌，因为这样做需要私钥。相反，您应该生成用户访问令牌。您应该通过您的应用平台推荐的机制存储令牌，并记住存储机制可能并非完全安全。
使用合适的令牌类型
GitHub 应用可以生成安装访问令牌或用户访问令牌以进行身份验证的 API 请求。
安装访问令牌会将活动归因于您的应用。这对于独立于用户运行的自动化非常有用。
用户访问令牌会将活动归因于用户和您的应用。这对于根据用户输入或代表用户采取行动非常有用。
安装访问令牌根据 GitHub 应用的权限和访问权限进行限制。用户访问令牌根据 GitHub 应用的权限和访问权限以及用户的权限和访问权限进行限制。因此，如果您的 GitHub 应用代表用户采取行动，它应该始终使用用户访问令牌而不是安装访问令牌。否则，您的应用可能会允许用户查看或执行他们不应该查看或执行的操作。
您的应用决不应该使用个人访问令牌或 GitHub 密码进行身份验证。
彻底且持久地授权
在登录用户后，应用开发者必须采取额外步骤以确保用户应该能够访问系统中的数据。每次登录都需要对用户的成员资格、访问权限和当前 SSO 状态进行新的检查。
使用持久的唯一id存储用户
当用户登录并在您的应用程序中执行操作时，您必须记住哪个用户执行了该操作，以便在下一次登录时向他们授予访问相同资源的权限。
要正确地在数据库中存储用户，请始终使用用户的id。此值永远不会更改，也不会用于指向不同的用户，因此它确保您正在向您想要的用户提供访问权限。您可以使用GET /userREST API 端点找到用户的id。请参阅“用户的 REST API 端点”。
如果您存储对仓库、组织和企业的引用，也请使用它们的id，以确保您对它们的链接保持准确。
决不要使用会随时间变化的标识符，包括用户句柄、组织slug或电子邮件地址。
验证每次新的身份验证的组织访问权限
当您使用用户访问令牌时，您应该跟踪该令牌被授权访问哪些组织。如果组织使用 SAML SSO 并且用户未执行 SAML SSO，则用户访问令牌将无法访问该组织。您可以使用GET /user/installationsREST API 端点来验证用户访问令牌可以访问哪些组织。如果用户未被授权访问组织，则应阻止其访问您自己的应用程序中的组织拥有数据，直到他们执行 SAML SSO 为止。更多信息，请参阅“GitHub 应用安装的 REST API 端点”。
使用组织和企业上下文存储用户数据
除了通过id字段跟踪用户身份外，您还应该保留每个用户在其下操作的组织或企业的的数据。这将有助于确保在用户切换角色时不会泄露敏感信息。
例如
- 用户位于需要 SAML SSO 的
Mona组织中，并在执行 SSO 后登录您的应用。您的应用现在可以访问用户在Mona中执行的任何操作。 - 用户从
Mona中的仓库中提取大量代码并将其保存在您的应用中进行分析。 - 之后，用户换了工作，并从
Mona组织中被移除。
当用户访问您的应用时，他们是否仍然可以在其用户帐户中看到来自Mona组织的代码和分析？
这就是为什么跟踪您的应用正在保存的数据的来源至关重要的原因。否则，您的应用将成为组织的数据保护威胁，如果他们无法信任您的应用能正确保护其数据，他们很可能会禁止您的应用。
令牌过期
GitHub 强烈建议您使用过期的用户访问令牌。如果您以前选择不使用过期的用户访问令牌，但想要重新启用此功能，请参阅“激活 GitHub 应用的可选功能”。
安装访问令牌在1小时后过期，用户访问令牌在8小时后过期，刷新令牌在6个月后过期。但是，您也可以在不再需要令牌时立即吊销它们。更多信息，请参见DELETE /installation/token（吊销安装访问令牌）和DELETE /applications/{client_id}/token（吊销用户访问令牌）。
缓存令牌
用户访问令牌和安装访问令牌旨在使用到它们过期为止。您应该缓存创建的令牌。在创建新令牌之前，请检查缓存以查看您是否已拥有有效令牌。重用令牌将使您的应用更快，因为它将减少生成令牌的请求次数。
制定安全漏洞处理计划
您应该制定一个计划，以便能够及时处理任何安全漏洞。
如果您的应用私钥或密钥泄露，您需要生成新的密钥或秘密，更新您的应用以使用新的密钥或秘密，并删除旧的密钥或秘密。
如果安装访问令牌、用户访问令牌或刷新令牌泄露，您应该立即吊销这些令牌。更多信息，请参见DELETE /installation/token（吊销安装访问令牌）和DELETE /applications/{client_id}/token（吊销用户访问令牌）。
定期进行漏洞扫描
您应该定期对您的应用进行漏洞扫描。例如，您可以为托管应用代码的存储库设置代码扫描和密钥扫描。更多信息，请参见关于代码扫描和关于密钥扫描。
选择合适的环境
如果您的应用在服务器上运行，请验证您的服务器环境安全且能够处理您应用预期的流量。
订阅最少数量的Webhook
只订阅您的应用所需的Webhook事件。这将有助于减少延迟，因为您的应用不会接收它不需要的有效负载。
使用Webhook密钥
您应该为您的GitHub App设置一个Webhook密钥，并验证传入Webhook事件的签名是否与密钥匹配。这有助于确保传入的Webhook事件是有效的GitHub事件。
更多信息，请参见使用GitHub Apps的Webhook。示例请参见构建响应Webhook事件的GitHub App。
留出时间让用户接受新的权限
当您向GitHub App添加存储库或组织权限时，已在其个人帐户或组织中安装该应用的用户将收到一封电子邮件，提示他们查看新的权限。在用户批准新权限之前，其应用安装只会接收旧权限。
更新权限时，您应该考虑使您的应用向后兼容，以便给您的用户时间来接受新的权限。您可以使用带有new_permissions_accepted操作属性的安装Webhook来了解用户何时接受应用的新权限。
安全地使用服务
如果您的应用使用第三方服务，则应安全地使用它们。
- 您的应用使用的任何服务都应具有唯一的登录名和密码。
- 应用不应共享服务帐户，例如电子邮件或数据库服务来管理您的SaaS服务。
- 只有具有管理职责的员工才应该拥有托管您的应用的基础设施的管理员访问权限。
添加日志记录和监控
考虑为您的应用添加日志记录和监控功能。安全日志可能包括：
- 身份验证和授权事件
- 服务配置更改
- 对象读取和写入
- 用户和组权限更改
- 提升为管理员角色
您的日志应为每个事件使用一致的时间戳，并应记录所有已记录事件的用户、IP地址或主机名。
启用数据删除
如果您的GitHub App可供其他用户或组织使用，则应为用户和组织所有者提供删除其数据的方法。用户不应需要发送电子邮件或致电支持人员才能删除其数据。