セキュリティ

私たちは、プライバシーは特権ではなく権利であり、当社の事業の根幹に組み込まれていると考えています。X Developer Platform を利用し、開発者ポリシーに従っていただくことで、X 上の公共の会話にプラットフォームが適切に資すること、そしてプライバシーへの取り組みが守られることに重要な役割を果たしていただきます。

ご自身と App のユーザーのデータを保護するため、セキュアな実装の重要性をあらためてお伝えします。セキュリティ侵害の脅威から守る責任はあなたにあり、X を利用する人々を保護することは私たちとの共通の責務です。本ページでは、安全なアプリケーションの構築およびデータとアクセスを可能な限り安全に保つための期待事項を説明します。

X Developer Platform で利用可能なセキュリティ技術（authentication、TLS、app permissions など）に加え、X のユーザー視点でのサードパーティアプリとセッションの利用についてもご確認ください。

​

セキュリティ問題の報告

X Developer Platform のユーザーは、セキュリティインシデントの発生が疑われる事象を初めて察知してから48時間以内に、X の脆弱性報告プログラムを通じて X に通知する必要があります。

​

セキュリティのベストプラクティス

X Developer Platformやインターネット全般で開発・構築する際は、これらを念頭に置いてください。

​

セキュリティ・バイ・デザイン

脅威モデリングの監査やペネトレーションテストの実施について、セキュリティ専門家の起用を検討してください。優れたセキュリティ企業であれば、課題を徹底的に洗い出します。X がこの考え方をどのように採用しているかは当社のブログ記事をご覧ください。

また、X はすべてのパートナーに対し、次の事項の遵守を求めています。

• コードをセキュアなリポジトリで管理すること。
• システム開発ライフサイクル（SDLC）全体を通じてリスク分析を実施すること。
• SDLC 全体でセキュリティ課題を特定し、適切に軽減（緩和）すること。
• SDLC プロセス全体で環境を分離することを確保すること。
• すべてのテスト欠陥を修正し、再テストしてクローズすること。

​

監視してアラートを受け取る

Webアプリに問題があるかもしれないと感じたとき、どうすれば確実に把握できるでしょうか。適切にログを記録し、重大な例外やエラーの通知を受け取れるようにしておきましょう。主要な指標をまとめたダッシュボードを用意し、異常の有無をひと目で確認できるようにすることも検討してください。

​

報告チャネルを作成する

ユーザーがあなたのAppで遭遇した可能性のあるセキュリティ問題について、容易に連絡できる手段を用意しましょう。Xのユーザーやdataに影響を及ぼす問題が見つかった場合は、その問題をXに報告する責任もあります。セキュリティインシデント発生時に、影響を受けたユーザーへ通知するためのアクションプラン／プロセスを事前に準備しておいてください。

​

適切なテスト

エンドツーエンドテストを十分に整備し、無許可アクセスなどのセキュリティシナリオで想定される失敗ケースを含むよう更新してください。攻撃者の視点に立ち、攻撃者がXのdataや正当な機能に無許可でアクセスすることを阻止することを想定したシステムテストを設計・実施しましょう。

​

API Key およびトークンの保護

X プラットフォームの開発者として、開発者用 App が承認されていることを前提に、X に保存されている自分の data とユーザーの data の両方にプログラム的にアクセスできます。すべての API リクエストは、開発者用 App のキーとシークレット、必要に応じて承認済みユーザーの access token を用いて OAuth により認証される必要があります。認証情報を安全に保つのは開発者であるあなたの責任です。

推奨されるベストプラクティスの例は以下のとおりです。

• パスワード／トークンの更新ローテーションを設ける。
• 機密データは常に必要に応じて暗号化し、復号は可能な限り下流で行う。
• ユーザーの access token は暗号化されたストアに保存する。
• 侵害の疑いがある場合は、キーおよびトークンを再生成または無効化する。

X 向けの OAuth を用いたデバッグや実装に関する詳細は、コミュニティフォーラムのセキュリティカテゴリをご覧ください。

​

入力の検証

ユーザーが有効で信頼できるデータを提供すると想定しないでください。X API のリクエストに含まれる可能性のある、ユーザーからのすべてのデータをサニタイズしてください。アプリケーションで受け入れ可能な入力の種類のみを許可リストに登録し、許可リストにないものはすべて破棄してください。

​

暗号化通信

X では、すべての API リクエストを TLS 経由で送信する必要があります。自社サーバーとの通信も、可能な限り暗号化してください。

​

露出されたデバッグ情報

デバッグ画面やログを通じて、機密性の高い X のデータや認証情報が露出していないことを必ず確認してください。アプリケーションの設定が不適切な場合、Web フレームワークによってはデバッグ情報に容易にアクセスできてしまいます。デスクトップやモバイルの開発では、デバッグフラグやシンボルを有効にしたまま誤ってビルドをリリースしてしまうことがよくあります。これらの設定に対するビルドチェックをデプロイ/ビルド工程に組み込んでください。さらに、レポート目的でスタックトレースやクラッシュダンプを共有する場合は、プライベートな X のユーザーデータが秘匿化（マスキング）されていることを確認してください。

​

未フィルタの入力、未エスケープの出力

入力バリデーションの覚えやすい考え方として FIEO（Filter Input, Escape Output）があります。

アプリケーションの外部から来るものはすべてフィルタします。たとえば、X API の data、Cookie のデータ、ユーザーが入力したフォームの値、URL パラメータ、データベースからのデータなどです。アプリケーションが送信するすべての出力はエスケープします。たとえば、データベースサーバーに送る SQL、ユーザーのブラウザに送る HTML、他システムに送る JSON 出力、シェルプログラムに送るコマンドなどです。

​

クロスサイトスクリプティング（XSS）

XSS 攻撃は、多くの指標でウェブ上でもっとも一般的なセキュリティ問題の一つです。攻撃者が自身の JavaScript コードをアプリケーション内に実行可能な形で紛れ込ませると、さまざまな不正行為が可能になります。信頼できないユーザー入力のデータを保存・表示する箇所はすべて、検証・サニタイズし、HTML エスケープを施す必要があります。これを適切に行うのは難しく、攻撃者には XSS を成立させる多様な手法 があります。使用している言語やウェブ開発フレームワークには、クロスサイトスクリプティング対策として広く利用され十分に検証された仕組みが用意されているはずです。必ず活用してください。

​

SQLインジェクション

アプリケーションでデータベースを使用している場合は、SQLインジェクションに注意が必要です。入力を受け付けるあらゆる箇所は、攻撃者が入力欄の想定範囲を逸脱してデータベースに侵入するための潜在的な標的となり得ます。SQLインジェクションに対して体系的に防御できるデータベース用ライブラリを使用してください。そうしたアプローチから外れて独自にSQLを書く場合は、この種の攻撃に晒されていないことを確認するため、厳密なテストを用意してください。SQLインジェクションへの主な対策は、SQL文を構築する前にエスケープ処理を行うこと、そしてパラメータ化クエリ（パラメータ化入力）で文を生成することの2つです。後者はプログラマーのミスが起きにくいため推奨されます。

​

クロスサイトリクエストフォージェリ（CSRF）

あなたのアプリケーションへのリクエストが、本当にあなたのアプリケーションから送られていると断言できますか？CSRF攻撃は、この不確実性を悪用し、サイトにログイン中のユーザーに対して、何らかの処理を行うURLを気づかれないまま開かせます。開発者用 App の場合、攻撃者があなたのアプリを悪用して、ユーザーに望まない Tweet を投稿させたり、スパムアカウントをフォローさせたりすることにつながり得ます。

CSRF への最も確実な対処法は、信頼できる場所に保存されたランダムなトークンをすべてのフォームに含め、正しいトークンがないフォームはエラーにすることです。最新のWebフレームワークにはこれを体系的に処理する仕組みがあり、運が良ければデフォルトで有効になっていることもあります。簡単な予防策（ただし、これだけに頼るべきではありません）は、データを作成・変更・削除するあらゆるアクションに POST リクエストを必須とすることです。

​

レートリミットがない場合

潜在的なスパマーや攻撃者の活動を抑止するため、適切な場面では CAPTCHA を使用してください。

---

X 自体に直接影響するセキュリティ上の問題を発見した場合は、脆弱性に関するバグバウンティプログラムをご利用ください。