最佳实践

你的 API 密钥和令牌应当被妥善、严格地保护。

这些凭据与你的开发者应用以及那些已授权你代表其发起请求的 X 账号直接关联。如果你的密钥遭到泄露，恶意行为者可能会利用它们代表你的开发者应用或其授权用户向 X 端点发起请求，这可能导致你触发意外的速率限制、耗尽你的付费访问配额，甚至使你的开发者应用被暂停。

以下各节提供了在管理 API 密钥和令牌时应考虑的最佳实践。

​

重新生成 API 密钥和令牌

如果你认为你的 API 密钥已被泄露，应按照以下步骤重新生成你的 API 密钥：

1. 前往开发者门户的“Projects and Apps”页面 或者 https://developer.x.com/zh/portal/projects-and-apps.html。
2. 点击相关应用旁边的“Keys and tokens”图标（🗝）。
3. 点击你想要重新生成的那组密钥和令牌旁边的“Regenerate”按钮。

如果你希望以编程方式重新生成 Access Token 或 Bearer Token，可以使用我们的认证端点实现。

• 如果你想重新生成 Access Token，必须先使用 POST oauth/invalidate_token 或者 /zh/resources/fundamentals/authentication/api-reference#post-oauth2-invalidate-token 端点使令牌失效，然后使用 3-legged OAuth flow 或者 /zh/resources/fundamentals/authentication/oauth-1-0a/obtaining-user-access-tokens 重新生成令牌。
• 如果你想重新生成 Bearer Token，必须先使用 POST oauth2/invalidate_token 或者 /zh/resources/fundamentals/authentication/api-reference#post-oauth2-invalidate-token 端点使令牌失效，然后使用 POST oauth2/token 或者 /zh/resources/fundamentals/authentication/api-reference#post-oauth2-token 端点重新生成令牌。

​

为你的机密信息准备一个集中管理的文件

使用 .ENV 或其他类型的 .yaml 文件来存放机密信息是可行且有帮助的做法，但务必配置严格的 .gitignore，以防不小心将这些内容提交到 Git 仓库。 

​

环境变量

编写利用环境变量的代码可能会很有帮助。 

下面是一个用 Python 编写的示例：

import os

consumer_key = os.environ.get("CONSUMER_KEY")

consumer_secret = os.environ.get("CONSUMER_SECRET")

在终端中，你可以输入类似以下命令：

export CONSUMER_KEY='xxxxxxxxxxxxxxxxxxx'
export CONSUMER_SECRET='xxxxxxxxxxxxxxxxxxxxxxx'

​

源代码与版本控制

开发者最常见的安全失误，是将 API 密钥和令牌提交到 GitHub、BitBucket 等可访问的版本控制系统中的源代码里。许多此类代码仓库对公众开放。在公共代码仓库中，这种错误屡见不鲜，甚至催生了专门抓取 API 密钥且获利颇丰的机器人。

• 使用服务器环境变量。将 API 密钥存放在环境变量中，可将其与代码与版本控制隔离开来，也便于在不同环境中使用不同的密钥。
• 使用不纳入源代码管理的配置文件。将文件名添加到你的 .gitignore 文件中，使其不被版本控制跟踪。
• 如果你是在启用版本控制后才从代码中移除了 API 密钥，那么通过访问代码库的历史版本仍可能获取到这些密钥。请按下一节所述重新生成你的 API 密钥。

​

数据库

如果需要在数据库中存储访问令牌，请注意以下事项：

• 限制对数据库的访问，确保只有令牌所有者可以读取该访问令牌。
• 限制存放访问令牌的数据库表的编辑/写入权限——应通过密钥管理系统实现自动化控制。
• 在写入任何数据存储之前，对访问令牌进行加密。

​

密码管理工具

诸如 1Password 或 LastPass 等密码管理工具有助于将你的密钥和令牌安全保存。建议不要在团队共享的密码管理工具中共享这些信息。

​

Web storage & cookies

Web storage 有两种类型：LocalStorage 和 SessionStorage。它们的出现是对使用 Cookie 的改进，因为 web storage 的容量远高于 Cookie。然而，这些存储方式各有优缺点。  

Web Storage: LocalStorage

存储在本地 web storage 中的内容是持久化的。这意味着数据会一直保留，直到被明确删除。根据你的项目需求，这可能是一项优势。然而，使用 LocalStorage 时应谨慎，因为对数据的任何更改或新增在今后访问该网页时都会生效并可用。我们通常不建议使用 LocalStorage，但在少数情况下可能例外。如果你决定使用 LocalStorage，需要了解它遵循同源策略，因此在此处存储的所有数据只能从相同源访问。使用 LocalStorage 的一个额外性能优势是可以减少客户端与服务器之间的通信量，因为每个 HTTP 请求不必将数据发送回服务器。  

Web Storage: SessionStorage

SessionStorage 与 LocalStorage 类似，但关键区别在于它不具备持久性。一旦用于写入 SessionStorage 的窗口（或标签页，取决于浏览器）被关闭，数据就会丢失。这有助于在单次用户会话内限制对令牌的读取访问。从安全角度考虑，相比 LocalStorage 通常更倾向于使用 SessionStorage。与 LocalStorage 一样，SessionStorage 同样受益于同源策略以及减少客户端与服务器之间的通信量。  

Cookies

Cookie 是更传统的会话数据存储方式。你可以为每个 Cookie 设置过期时间，从而便于撤销与访问控制。然而，使用 Cookie 会显著增加客户端与服务器之间的通信量，因为每个 HTTP 请求都会将数据发送回服务器。如果你决定使用 Cookie，需要防范会话劫持。默认情况下，Cookie 会通过 HTTP 明文发送，这使其内容易受数据包嗅探和/或中间人攻击，攻击者可能篡改你的流量。你应始终强制使用 HTTPS 以保护传输中的数据，这将提供机密性、完整性以及认证。然而，如果你的 Web 应用或站点同时通过 HTTP 和 HTTPS 提供访问，还应在 Cookie 上使用“Secure”标记。这样可防止攻击者向用户发送你站点的 HTTP 版本链接并窃听由此产生的 HTTP 请求。

在使用 Cookie 时，防范会话劫持的另一种辅助性防御措施是在执行任何高影响操作之前再次验证用户身份。提高 Cookie 安全性时另一个需要考虑的标记是“HttpOnly”。该标记告知浏览器相关 Cookie 只能由服务器端访问。任何由客户端脚本尝试访问的行为都会被该标记禁止，从而有助于防御大多数跨站脚本（XSS）攻击。