安全

我们坚信隐私是权利而非特权，这一原则已融入公司的基石。通过使用 X 开发者平台并遵守我们的开发者政策，您在确保平台服务于 X 上的公共讨论、并维护我们对隐私的承诺方面发挥着关键作用。

我们提醒您，以安全为先进行构建至关重要，以保护您自身及您的 App 用户的数据。防范安全漏洞是您的责任，而保护使用 X 的人是我们共同的责任。本文阐述了对安全构建应用以及尽可能保障数据与访问安全的相关期望。

请了解适用于 X Developer Platform 的各类安全技术，包括身份验证、TLS 和应用权限；同时，也请从 X 用户角度了解使用第三方应用和会话。

​

报告安全问题

X Developer Platform 的用户在初步怀疑发生安全事件后，必须在 48 小时内通过 X 的漏洞报告计划 通知 X。

​

安全最佳实践

在基于 X 开发者平台进行构建以及在互联网上的其他场景中，请牢记以下要点。

​

以安全为设计原则

考虑聘请安全专家开展威胁建模审计和/或渗透测试。优秀的安全公司会深入排查以发现问题。关于 X 如何践行这一理念，可阅读我们的博客文章。

此外，X 要求所有合作伙伴对以下事项负责：

• 在安全的代码仓库中维护代码。
• 在整个系统开发生命周期（SDLC）内开展风险分析。
• 确保在 SDLC 全程识别并缓解安全问题。
• 确保在 SDLC 各阶段实现环境隔离。
• 确保所有测试缺陷均已修复、复测并关闭。

​

监控与告警

如果你怀疑 Web 应用出现了问题，如何确认？务必做好日志记录，并确保能接收到关键异常和错误的通知。你也可以搭建关键指标的仪表板，便于一眼判断是否有故障发生。

​

创建报告渠道

为你的用户提供便捷的联系方式，便于他们就使用你的 App 时遇到的潜在安全问题与你联系。如果发现的问题会影响 X 的用户和 data，你也有责任向 X 报告该问题。请预先制定并准备好在发生安全事件时通知受影响用户的行动计划/流程。

​

充分测试

确保你的端到端测试全面且持续更新，将安全场景（如未授权访问）的预期失败纳入其中。以攻击者思维进行审视，并设置系统级测试，确保在攻击者试图未经授权访问 X data 或滥用已授权功能时能将其拦阻。

​

保护 API 密钥和令牌

作为 X 平台的开发者，只要用户已授权你的开发者 App，你即可通过编程方式访问由 X 存储的你的数据以及用户的数据。所有 API 请求都必须使用 OAuth，并通过你的开发者 App 的 key 和 secret 进行身份验证，在某些情况下还需要授权用户的Access Tokens。你有责任确保你的凭据安全。

以下是一些推荐的最佳实践：

• 建立密码/令牌的定期轮换与刷新机制。
• 按需始终对敏感数据进行加密，避免过早在上游环节解密。
• 将用户的 access token 存储在加密的存储中。
• 如果你认为密钥和令牌已遭泄露，请重新生成或作废相关密钥和令牌。

有关在 X 上使用 OAuth 进行调试和开发的更多讨论，请访问社区论坛的安全分类。

​

输入验证

不要假设用户会提供有效、可信的数据。对所有来自用户、且可能用于 X API 请求的数据进行净化。采用“允许列表”来限定应用可接受的输入类型，并丢弃所有不在允许列表中的内容。

​

加密通信

X 要求所有 API 请求均通过 TLS 进行。与您自有服务器之间的通信也应尽可能加密。

​

暴露的调试信息

请确保不要通过调试界面或日志泄露敏感的 X 数据或凭据。如果应用未正确配置，某些 Web 框架可能会让获取调试信息变得过于容易。对于桌面和移动端开发者，也很容易不小心在启用调试标志或符号的情况下打包并发布构建。请在部署/构建流程中加入针对这些配置的构建检查。此外，如果为报告共享堆栈跟踪或崩溃转储，请确保已对私有 X 用户的数据进行脱敏处理。

​

未过滤的输入，未转义的输出

一个便于记忆的输入验证原则是 FIEO：过滤输入（Filter Input），转义输出（Escape Output）。

过滤所有来自应用程序外部的内容，包括 X API data、cookie data、用户提交的表单输入、URL 参数、来自数据库的数据等。对应用程序发出的所有输出进行转义，包括发送到数据库服务器的 SQL、发送到用户浏览器的 HTML、发送到其他系统的 JSON 输出，以及发送给 shell 程序的命令。

​

跨站脚本（XSS）

XSS 攻击按多数衡量标准来看，是 Web 上最常见的安全问题类型。如果攻击者能将其自有的 JavaScript 代码注入你的应用，他们就可能做出恶意操作。凡是你存储并展示不受信任的用户提供数据的地方，都需要进行检查、清理，并进行 HTML 转义。要把这件事做好并不容易，因为黑客有多种方式实施 XSS 攻击。你的编程语言或 Web 开发框架很可能已有流行且经过充分验证的跨站脚本防护机制；请务必加以采用。

​

SQL 注入

如果你的应用程序使用了数据库，你需要了解SQL 注入。凡是接收输入的地方，都可能成为攻击者的目标：他们可能会“跳出”输入字段，进而访问你的数据库。请使用能以系统化方式防护 SQL 注入的数据库库。若你绕开这种方式自行编写 SQL，请编写严格的测试，确保不会将自己暴露于此类攻击。防御 SQL 注入的两种主要方法是：在构造 SQL 语句前对输入进行转义，以及使用参数化输入来创建语句。建议采用后者，因为它更不易出现程序员失误。

​

跨站请求伪造（CSRF）

是否能确保发送到您的应用的请求确实来自您的应用？CSRF 攻击会利用这一点，诱使已登录您网站的用户在不知情的情况下访问执行操作的 URL。对于开发者 App，这可能意味着攻击者利用您的应用强迫用户发布不想要的 Tweets，或关注垃圾账号。

应对 CSRF 的最稳妥方法是在每个表单中包含一个随机令牌，并将其存放在可信位置；如果表单未携带正确令牌，则抛出错误。现代 Web 框架通常提供系统化的处理方式，甚至在某些情况下默认启用。一个简单的预防措施（但绝非唯一应采取的措施）是让任何创建、修改或销毁 data 的操作都必须使用 POST 请求。

​

缺乏请求速率限制

在合适的场景下使用 CAPTCHA，以减缓潜在垃圾信息发送者和攻击者的行为速度。

---

如果您发现了直接影响 X 本身的安全问题，我们提供漏洞赏金计划。