选择所需的最低权限
注册 GitHub 应用程序时，请选择 GitHub 应用程序所需的最低权限。如果应用程序的任何密钥或令牌遭到泄露，这将限制可能造成的损害。有关如何选择权限的更多信息，请参阅“为 GitHub 应用程序选择权限”。
当您的 GitHub 应用创建安装访问令牌或用户访问令牌时，您可以进一步限制应用可以访问的仓库以及令牌具有的权限。有关更多信息，请参阅“为 GitHub 应用生成安装访问令牌”和“为 GitHub 应用生成用户访问令牌”。
保持在速率限制内
订阅 Webhook 事件，而不是轮询 API 获取数据。这将有助于您的 GitHub 应用保持在 API 速率限制内。有关更多信息，请参阅“使用 GitHub 应用的 Webhook”和“构建响应 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 密码进行身份验证。
验证每次新身份验证的组织访问权限
当您使用用户访问令牌时，应跟踪该令牌被授权访问的组织。如果某个组织使用 SAML SSO 且用户尚未执行 SAML SSO，则用户访问令牌不应访问该组织。您可以使用 GET /user/installations REST API 端点来验证用户访问令牌可以访问哪些组织。如果用户无权访问某个组织，您应拒绝其访问，直到他们执行 SAML SSO 为止。有关更多信息，请参阅“GitHub App 安装的 REST API 端点”。
令牌过期
GitHub 强烈建议您使用过期的用户访问令牌。如果您之前选择不使用过期的用户访问令牌，但现在想要重新启用此功能，请参阅“为 GitHub App 激活可选功能”。
安装访问令牌在 1 小时后过期，过期的用户访问令牌在 8 小时后过期，刷新令牌在 6 个月后过期。但是，您也可以在不再需要令牌时立即撤销它们。有关更多信息，请参阅“DELETE /installation/token”以撤销安装访问令牌，以及“DELETE /applications/{client_id}/token”以撤销用户访问令牌。
缓存令牌
用户访问令牌和安装访问令牌旨在使用到过期为止。您应该缓存您创建的令牌。在创建新令牌之前，请检查您的缓存以查看您是否已拥有有效的令牌。重复使用令牌将使您的应用程序更快，因为它将减少生成令牌的请求次数。
制定处理安全漏洞的计划
您应该制定一个计划，以便能够及时处理任何安全漏洞。
如果您的应用程序的私钥或密钥被泄露，您需要生成新的密钥或密钥，更新您的应用程序以使用新的密钥或密钥，并删除旧的密钥或密钥。
如果安装访问令牌、用户访问令牌或刷新令牌被泄露，您应立即撤销这些令牌。有关更多信息，请参阅 "DELETE /installation/token" 以撤销安装访问令牌，以及 "DELETE /applications/{client_id}/token" 以撤销用户访问令牌。
定期进行漏洞扫描
您应该定期对您的应用程序进行漏洞扫描。例如，您可以为托管应用程序代码的存储库设置代码扫描和秘密扫描。有关更多信息，请参阅 "关于代码扫描" 和 "关于秘密扫描."
选择合适的环境
如果您的应用程序在服务器上运行，请验证您的服务器环境是否安全，以及它是否能够处理您对应用程序预期的流量量。
订阅最少的 Webhook
仅订阅您的应用程序需要的 Webhook 事件。这将有助于减少延迟，因为您的应用程序不会收到它不需要的有效负载。
使用 Webhook 密钥
您应该为您的 GitHub 应用程序设置一个 Webhook 密钥，并验证传入 Webhook 事件的签名是否与密钥匹配。这有助于确保传入的 Webhook 事件是一个有效的 GitHub 事件。
有关更多信息，请参阅 "使用 Webhook 与 GitHub 应用程序." 例如，请参阅 "构建响应 Webhook 事件的 GitHub 应用程序."
留出时间让用户接受新的权限
当您向 GitHub 应用添加仓库或组织权限时，在个人帐户或组织中安装了该应用的用户会收到一封电子邮件，提示他们查看新的权限。在用户批准新的权限之前，他们的应用安装只会收到旧的权限。
更新权限时，您应该考虑使您的应用向后兼容，以便为用户提供时间接受新的权限。您可以使用 带有 new_permissions_accepted 操作属性的安装 Webhook 来了解用户何时接受了您应用的新权限。
以安全的方式使用服务
如果您的应用使用第三方服务，则应以安全的方式使用它们。
- 您的应用使用的任何服务都应具有唯一的登录名和密码。
- 应用不应共享服务帐户（例如电子邮件或数据库服务）来管理您的 SaaS 服务。
- 只有具有管理职责的员工才能对托管您的应用的基础设施拥有管理员访问权限。
添加日志记录和监控
考虑为您的应用添加日志记录和监控功能。安全日志可能包括
- 身份验证和授权事件
- 服务配置更改
- 对象读取和写入
- 用户和组权限更改
- 将角色提升为管理员
您的日志应为每个事件使用一致的时间戳，并应记录所有已记录事件的用户、IP 地址或主机名。
启用数据删除
如果您的 GitHub 应用可供其他用户或组织使用，您应该为用户和组织所有者提供删除其数据的方法。用户不应需要通过电子邮件或电话联系支持人员才能删除其数据。