Skip to main content
API キーとトークンは細心の注意を払って保護する必要があります。 これらの認証情報は、あなたの デベロッパーアプリ と、あなたに代わってリクエストを行うことを許可した X アカウントに直接紐づいています。キーが漏洩すると、悪意のある第三者がそれらを使ってあなたのデベロッパーアプリまたはその認可済みユーザーに代わって X エンドポイントにリクエストを送る可能性があります。その結果、想定外のレート制限に達したり、有料アクセスの割り当てを使い果たしたり、さらにはデベロッパーアプリが停止される可能性もあります。 以下のセクションでは、API キーとトークンを管理する際に検討すべきベストプラクティスを紹介します。

​
API キーとトークンを再生成する

API キーが漏洩したと思われる場合は、以下の手順で API キーを再生成してください:
  1. Developer Console の「Apps」ページ に移動します。
  2. 該当するアプリの横にある「Keys and tokens」アイコン (🗝) をクリックします。
  3. 再生成したいキーとトークンのセットの横にある「Regenerate」ボタンをクリックします。
Access Token または Bearer Token をプログラム的に再生成したい場合は、認証エンドポイントを使用できます。

​
シークレット用の集中ファイルを持つ

.ENV ファイルやその他の .yaml ファイルなど、シークレットを格納するファイルを利用することは有効な選択肢の 1 つですが、誤って git リポジトリにコミットしないよう、しっかりとした .gitignore ファイルを用意してください。

​
環境変数

環境変数を利用するコードを書くことも役立ちます。 以下は 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'

​
ソースコードとバージョン管理

デベロッパーが犯す最も一般的なセキュリティミスは、GitHub や BitBucket などのアクセス可能なバージョン管理システムに API キーとトークンをコミットしてしまうことです。これらのコードリポジトリの多くは公開されています。この間違いは公開コードリポジトリで頻繁に発生しており、API キーをスクレイピングする収益性の高いボットが存在するほどです。
  • サーバーの環境変数を使用してください。API キーを環境変数に格納することで、コードやバージョン管理から切り離せます。これによって環境ごとに異なるキーを簡単に使用することも可能になります。
  • ソース管理から除外した設定ファイルを使用してください。ファイル名を .gitignore ファイルに追加して、そのファイルがバージョン管理で追跡されないようにします。
  • バージョン管理を使用した後にコードから API キーを削除しても、以前のコードベースにアクセスすれば依然として API キーにアクセスできる可能性があります。次のセクションで説明するとおり、API キーを再生成してください。

​
データベース

access token をデータベースに保存する必要がある場合は、以下の点に留意してください:
  • データベースへのアクセスを制限し、access token がそのトークンの所有者のみに読み取り可能となるようにします。
  • access token を格納するデータベーステーブルへの編集/書き込み権限を制限してください — これはキー管理システムで自動化する必要があります。
  • データストアに保存する前に access token を暗号化してください。

​
パスワード管理ツール

1password や Last Pass などのパスワード管理ツールは、キーとトークンを安全な場所に保管するのに役立ちます。共有チームのパスワード管理ツール内でこれらを共有することは避けたほうがよいでしょう。

​
Web ストレージとクッキー

Web ストレージには 2 種類あります: LocalStorage と SessionStorage。Web ストレージのストレージ容量は Cookie ストレージよりもはるかに大きいため、これらは Cookie を使用する場合の改善として作成されました。ただし、これらのストレージオプションにはそれぞれ異なる利点と欠点があります。 Web ストレージ: LocalStorage ローカル Web ストレージに保存されたものは永続的です。つまり、明示的に削除されるまでデータは保持されます。プロジェクトのニーズによっては、これを利点と捉えることもあります。ただし、対象の Web ページへの以降のすべての訪問でデータへの変更/追加が利用可能になるため、LocalStorage の使用には注意が必要です。通常、いくつかの例外を除いて LocalStorage の使用は推奨しません。LocalStorage を使用する場合、同一オリジンポリシーをサポートしているため、ここに保存されるすべてのデータは同じオリジン経由でのみアクセスできる点を覚えておいてください。データを HTTP リクエストのたびにサーバーに送り返す必要がないため、クライアント-サーバー間のトラフィックが減るというパフォーマンス上のメリットもあります。 Web ストレージ: SessionStorage SessionStorage は LocalStorage に似ていますが、大きな違いは SessionStorage が永続的ではないことです。SessionStorage への書き込みに使用したウィンドウ (使用しているブラウザーによってはタブ) が閉じられると、データは失われます。これは、ユーザーセッション内でトークンへの読み取りアクセスを制限するのに便利です。セキュリティの観点で考えると、通常は LocalStorage よりも SessionStorage を使うほうが好ましいです。LocalStorage と同様に、同一オリジンポリシーのサポートやクライアント-サーバー間のトラフィック減少のメリットは SessionStorage にも適用されます。 Cookie Cookie はセッションデータを保存するより従来からの方法です。各 Cookie に有効期限を設定でき、これによってアクセスの取り消しや制限が容易になります。ただし、Cookie を使用するとデータは HTTP リクエストのたびにサーバーに送り返されるため、クライアント-サーバー間のトラフィックは確実に増加します。Cookie を使用する場合、セッションハイジャックから保護する必要があります。デフォルトでは、Cookie は HTTP でプレーンテキストで送信されるため、内容がパケットスニッフィングや、攻撃者がトラフィックを改ざんする中間者攻撃に対して脆弱になります。通信中のデータを保護するために HTTPS を必ず強制してください。これにより、機密性、(データの) 整合性、および認証が提供されます。ただし、Web アプリケーションやサイトが HTTP と HTTPS の両方で利用可能な場合は、Cookie に ‘Secure’ フラグも使用するとよいでしょう。これにより、攻撃者がサイトの HTTP バージョンへのリンクをユーザーに送り、それに伴って生成される HTTP リクエストを盗聴することを防げます。 Cookie を使用する際のセッションハイジャックに対する二次的な防御としては、影響の大きいアクションを実行する前に再度ユーザーの身元を検証する方法があります。Cookie のセキュリティを高めるために検討するもう 1 つのフラグは ‘HttpOnly’ フラグです。このフラグは、対象の Cookie が指定されたサーバーからのみアクセス可能であることをブラウザーに伝えます。クライアント側のスクリプトによる試行はこのフラグにより禁止されるため、ほとんどのクロスサイトスクリプティング (XSS) 攻撃から保護するのに役立ちます。