セキュリティ

私たちは、プライバシーは特権ではなく権利であり、当社の基盤に組み込まれていると考えています。X Developer Platform を利用し、開発者ポリシーを遵守することで、X 上の公共の会話に資するプラットフォームであり続け、プライバシーへの当社のコミットメントを守るうえで、皆さまは重要な役割を担います。

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

ご注意ください: X Developer Platform で利用可能なセキュリティ技術（認証、TLS、アプリの権限）に加え、X ユーザーの観点からのサードパーティ製アプリケーションとセッションの使用についてもご留意ください。

​

セキュリティ問題の報告

X Developer Platform のユーザーは、セキュリティインシデントの発生を疑った時点から48時間以内に、X の脆弱性報告プログラムを通じて X に通知しなければなりません。

​

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

X のデベロッパープラットフォームで開発する際はもちろん、インターネット全体でも、これらを常に念頭に置いてください。

​

設計段階からのセキュリティ

脅威モデルの監査やペネトレーションテストの実施を検討してください。優れたセキュリティ企業は、問題を洗い出すために徹底的に調査します。X がこの考え方をどのように取り入れているかは、こちらのブログ記事をご覧ください。

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

• セキュアなリポジトリでコードを管理すること
• システム開発ライフサイクル（SDLC）全体を通じてリスク分析を実施すること
• SDLC 全体でセキュリティ上の問題を特定し、対処（緩和）すること
• SDLC の各工程で環境を分離すること
• すべてのテスト不具合を修正し、再テストのうえ、クローズすること

​

監視とアラートの設定

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

​

レポート用の連絡チャネルを用意する

ユーザーがアプリで発生した可能性のあるセキュリティ問題について、容易に連絡できるようにしておきましょう。X のユーザーやデータに影響を及ぼす問題が見つかった場合は、この問題を X に報告する責任もあります。セキュリティインシデント発生時に影響を受けたユーザーへ通知するための対応計画・手順を事前に準備しておいてください。

​

適切なテスト

エンドツーエンドテストを十分に実施し、無許可アクセスなどのセキュリティシナリオで想定される失敗ケースも取り込んで最新の状態に保ってください。攻撃者の思考で考え、攻撃者が X のデータや正規の機能へ不正アクセスすることを阻止できることを検証するシステムテストを設計してください。

​

API キーとトークンの保護

X プラットフォームの開発者は（あなたの開発者アプリがユーザーによって承認されていることを前提に）、X に保存されている自分のデータおよびユーザーデータにプログラムからアクセスできます。すべての API リクエストは、開発者アプリのキーとシークレット、場合によっては承認済みユーザーのアクセス トークンを用いた OAuth により認証される必要があります。資格情報の安全管理はあなたの責任です。

推奨されるベストプラクティスの一部は次のとおりです。

• パスワード／トークンのローテーション（定期的な更新）を実施する。
• 機密データは必要に応じて常に暗号化し、処理の早い段階での過度な復号は避ける。
• ユーザーのアクセス トークンは暗号化ストアに保存する。
• 侵害の恐れがある場合は、キーやトークンを再生成または無効化する。

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

​

入力検証

ユーザーが常に有効で信頼できるデータを提供するとは限らないと考えてください。X API のリクエストに含まれる可能性がある、ユーザー由来のすべてのデータは必ずサニタイズしましょう。アプリケーションで許容する入力の種類を事前に許可リストで定義し、リストにないものはすべて破棄してください。

​

暗号化通信

X では、すべての API リクエストを TLS 経由で行うことを必須としています。自社サーバーとの通信についても、可能な限り暗号化してください。

​

デバッグ情報の露出

デバッグ画面やログを通じて、X の機密データや認証情報が露出しないよう必ず確認してください。アプリケーションの設定が不適切だと、いくつかの Web フレームワークではデバッグ情報に簡単にアクセスできてしまいます。デスクトップやモバイルの開発では、デバッグ用のフラグやシンボルを有効にしたまま誤ってビルドを出荷してしまうことがあります。これらの設定に対するチェックをデプロイ／ビルドプロセスに組み込みましょう。さらに、レポーティングのためにスタックトレースやクラッシュダンプを共有する場合は、非公開の X ユーザーのデータが適切にマスキング（編集）されていることを確認してください。

​

無加工の入力、非エスケープの出力

入力検証を覚えやすくする合言葉が FIEO（Filter Input, Escape Output）です。

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

​

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

XSS 攻撃は、あらゆる指標で見てもウェブにおける最も一般的なセキュリティ問題の一つです。攻撃者が自分の JavaScript コードをアプリに実行させることができれば、様々な不正行為が可能になります。信頼できないユーザー提供データを保存・表示するあらゆる箇所では、検証・サニタイズ・HTML エスケープを行う必要があります。これを正しく実装するのは難しく、ハッカーには XSS を成立させる多様な手口 が存在します。使用している言語やウェブ開発フレームワークには、クロスサイトスクリプティング対策として広く使われ検証された仕組みが用意されているはずです。必ず活用してください。

​

SQL インジェクション

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

​

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

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

CSRF への最も確実な対処は、信頼できる場所に保存したランダムなトークンをあらゆるフォームに含め、正しいトークンがないフォームからのリクエストはエラーとして拒否することです。最新の Web フレームワークには体系的な対処方法が用意されており、場合によってはデフォルトで有効になっていることもあります。簡単な予防策（ただし、唯一の対策ではありません）は、data を作成・変更・削除するアクションには必ず POST リクエストを要求することです。

​

レート制限の欠如

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

---

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