最佳实践

应当非常谨慎地保护你的密钥和令牌。

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

以下部分包含在管理密钥和令牌时应考虑的最佳实践。

​

重新生成 API 密钥和令牌

如果您认为自己的 API 密钥已遭泄露，请按照以下步骤重新生成 API 密钥：

1. 前往 developer portal 的“Projects and Apps”页面。
2. 点击相关 App 旁的“Keys and tokens”图标（🗝）。
3. 在需要重新生成的密钥和令牌组旁点击“Regenerate”按钮。

如果您希望通过编程方式重新生成 Access Tokens 或 Bearer Tokens，可使用我们的身份验证 endpoint 实现。

• 若要重新生成 Access Tokens，必须先使用 POST oauth/invalidate_token endpoint 使现有令牌失效，然后通过 3-legged OAuth flow 重新获取令牌。
• 若要重新生成 Bearer Token，必须先使用 POST oauth2/invalidate_token endpoint 使现有令牌失效，然后使用 POST oauth2/token endpoint 重新获取令牌。

​

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

可以使用一个文件（例如 .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 Key 和密钥和令牌 提交到 GitHub、BitBucket 等可访问的版本控制系统中的源代码里。许多此类代码仓库对公众开放。在公共代码仓库中这种错误屡见不鲜，甚至催生了专门抓取 API Key 以牟利的机器人。

• 使用服务器环境变量。将 API Key 存放在环境变量中，可将其与代码和版本控制隔离；这也便于在不同环境中轻松使用不同的密钥。
• 使用不纳入源代码管理的配置文件。将该文件名添加到你的 .gitignore 文件中，以使其不被版本控制跟踪。
• 如果你在启用版本控制后才从代码中移除了 API Key，仍可通过查看代码库的历史版本访问到这些 API Key。请根据下一节的说明重新生成你的 API Key。

​

数据库

如果你需要在数据库中存储你的 access token，请注意以下事项：

• 限制对数据库的访问，确保 access token 仅由令牌所有者可读取。
• 限制用于存储 access token 的数据库表的编辑/写入权限——应通过密钥管理系统自动化地进行管理。
• 在写入任何 data 存储之前加密 access token。

​

密码管理工具

诸如 1Password 或 LastPass 等密码管理工具有助于将你的密钥和令牌安全保存。你可能应避免在团队共用的密码管理工具中共享这些信息。

​

Web storage 与 cookies

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

Web Storage：LocalStorage

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

Web Storage：SessionStorage

SessionStorage 与 LocalStorage 类似，但关键区别在于 SessionStorage 非持久化。一旦用于写入 SessionStorage 的窗口（或标签页，取浏览器而定）被关闭，数据就会丢失。这有助于在单个用户会话内限制对令牌的读取访问。从安全角度看，相较于 LocalStorage，通常更倾向于使用 SessionStorage。与 LocalStorage 一样，同源策略的支持以及减少客户端与服务器通信量的优势同样适用于 SessionStorage。  

Cookies

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

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