跳转到主要内容我们相信隐私是每个人的权利，而非特权，并将其融入公司的根基之中。通过使用 X 开发者平台并遵守我们的开发者政策，您在确保平台服务于 X 上的公共对话并维护我们对隐私的承诺方面发挥着关键作用。
我们想提醒您，安全构建对于保护您自身以及应用用户的数据至关重要。防范安全漏洞是您的职责，而保护使用 X 的人是我们共同的责任。本文说明了关于构建安全应用以及尽可能保障数据与访问安全的相关期望。
X Developer Platform 的用户在首次怀疑发生安全事件后，须在不超过 48 小时内通过 X 的漏洞报告计划通知 X。
在使用 X 开发者平台及更广泛的互联网进行构建时，请牢记这些要点。
考虑聘请安全专家开展威胁建模审计和/或渗透测试。优秀的安全公司会深入排查以发现问题。参阅我们的博文此处了解 X 如何践行这一理念。
此外，X 要求所有合作伙伴对以下事项负责：
- 在安全的代码仓库中维护代码。
- 在系统开发生命周期（SDLC）全过程开展风险分析。
- 确保在整个 SDLC 中识别并缓解安全问题。
- 确保在 SDLC 全过程中实现环境隔离。
- 确保所有测试缺陷均已修复、复测并关闭。
如果你怀疑你的 Web 应用出现了问题，怎样才能确定？务必做好日志记录，并确保在发生关键异常和 errors 时收到通知。你也可以搭建一个关键指标看板，便于一眼察觉是否有异常。
为你的用户提供便捷的联系方式，以便他们就你的应用中遇到的潜在安全问题与你联系。若发现的问题影响到 X 的用户或数据，你也有责任向 X 报告该问题。同时准备好在发生安全事件时用于通知受影响用户的行动计划/流程。
确保端到端测试全面且及时更新，并将安全场景（如未授权访问）的预期失败纳入其中。将自己置于攻击者的视角，设置系统测试，以确保能够阻止攻击者对 X 数据或受权限保护的功能进行未授权访问。
作为 X 平台的开发者，只要用户已授权你的开发者应用，你即可通过编程方式访问你自己的 data 以及由 X 存储的用户 data。所有 API 请求都必须使用 OAuth，并通过你的开发者应用的 key 和 secret 进行认证（或在中文版文档中使用认证），在某些情况下还需要授权用户的访问令牌（或访问令牌）。你有责任确保你的凭据安全。
以下是一些建议的最佳实践：
- 建立密码/令牌的定期轮换机制。
- 根据需要始终加密敏感数据，并避免在过早的上游环节解密数据。
- 将用户的访问令牌存储在加密的存储中。
- 如果你认为密钥和令牌已被泄露，请重新生成或使其失效（在中文版文档中参见重新生成或使其失效）。
有关在 X 上使用 OAuth 进行调试和开发的更多讨论，请访问社区论坛的安全分类。
不要假定用户会提供有效、可信的数据。对所有来自用户、且可能最终用于 X API 请求的数据进行净化处理。使用允许列表明确你的应用可接受的输入类型，并丢弃所有不在允许列表中的内容。
X 要求所有 API 请求均通过 TLS 传输。与您自有服务器之间的通信也应尽可能加密。
请确保不要通过调试界面或日志泄露敏感的 X 数据或凭据。如果应用未正确配置，一些 Web 框架会使获取调试信息变得容易。对于桌面和移动端开发者，可能会不小心在启用调试标志或符号的情况下发布构建。请在部署/构建流程中加入对此类配置的构建检查。此外，如果为报告而共享堆栈跟踪或崩溃转储，请确保已对私有 X 用户的数据进行脱敏处理。
一种便于记忆的输入验证方法是 FIEO：过滤输入（Filter Input），转义输出（Escape Output）。
过滤所有来自应用程序外部的内容，包括 X API 数据、cookie 数据、用户提交的表单输入、URL 参数、来自数据库的数据等。对应用程序发出的所有输出进行转义，包括发送到数据库服务器的 SQL、发送到用户浏览器的 HTML、发送到其他系统的 JSON 输出，以及发送到 Shell 程序的命令。
按多数衡量标准，XSS 攻击是 Web 上最常见的安全问题之一。如果攻击者能将其自有的 JavaScript 代码注入你的应用，就可能造成严重危害。凡是存储并展示不受信任的用户输入的地方，都需要进行检查、清理，并进行 HTML 转义。要把这件事做对并不容易，因为黑客有多种途径实施 XSS 攻击。你的编程语言或 Web 开发框架很可能提供了成熟、经过充分验证的跨站脚本防护机制；请务必使用它。
如果你的应用使用了数据库，需要了解SQL 注入。任何接受输入的地方都可能成为攻击者从输入字段逃逸并侵入数据库的入口。请使用能系统性防范 SQL 注入的数据库库。若脱离该方式而编写自定义 SQL，请编写充分而严格的测试，确保不会暴露于此类攻击。防御 SQL 注入的两种主要方法是：在构造 SQL 语句前对输入进行转义，或使用参数化输入创建语句。推荐采用后者，因为更不易出现开发者失误。
你能确保发往你的应用的请求确实来自你的应用吗？CSRF 攻击正是利用这种不确定性，诱使你站点中已登录的用户在不知情的情况下打开会执行操作的 URL。对于开发者应用，这可能意味着攻击者借你的应用强迫用户发布不想要的 Tweet 或关注垃圾账号。
应对 CSRF 最稳妥的方法是在每个表单中包含一个随机令牌，并将其存储在可信位置；如果表单没有正确的令牌，则抛出错误。现代 Web 框架提供了系统化的处理方式，甚至很多情况下默认已开启。一个简单的预防措施（但绝非唯一应采取的措施）是要求任何创建、修改或删除数据的操作都必须使用 POST 请求。
在适当情况下使用 CAPTCHA，减缓潜在的垃圾信息发送者和攻击者的行为。
如果你发现了直接影响 X 的安全问题，我们提供漏洞赏金计划。 
