メインコンテンツへスキップ
APIキーとトークンは厳重に保護してください。  これらの認証情報は、あなたのアプリおよび、あなたが代理でのリクエストを許可したXアカウントに直接結び付いています。キーが漏えいすると、悪意ある第三者があなたのアプリやその承認ユーザーの代理としてXのエンドポイントにリクエストを送信できてしまい、想定外のレート制限に達したり、有料アクセス枠を使い切ったり、最悪の場合はあなたのアプリが停止されるおそれがあります。 以下のセクションでは、APIキーとトークンを管理する際に考慮すべきベストプラクティスを示します。

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

APIキーが漏えいした可能性がある場合は、次の手順に従ってAPIキーを再生成してください。
  1. 開発者ポータルの「Projects and Apps」ページに移動します。
  2. 対象のアプリの横にある「Keys and tokens」アイコン（🗝）をクリックします。
  3. 再生成したいキーとトークンのセットの横にある「Regenerate」ボタンをクリックします。 
Access Tokens または Bearer Tokens をプログラムで再生成したい場合は、認証エンドポイントを使用して実行できます。
  • Access Tokens を再生成したい場合は、POST oauth/invalidate_token エンドポイントを使用してトークンを無効化し、その後 3-legged OAuth flow を使用してトークンを再生成してください。
  • Bearer Token を再生成したい場合は、POST oauth2/invalidate_token エンドポイントを使用してトークンを無効化し、その後 POST oauth2/token エンドポイントを使用してトークンを再生成してください。

​
シークレットを集中管理するファイルを用意する

シークレットを格納するために .env ファイルや .yaml などのファイルを用意するのは有用な選択肢ですが、これらを誤って 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 は暗号化してください。

​
パスワード管理ツール

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

​
Web storage & cookies

Web storage には LocalStorage と SessionStorage の 2 種類があります。Web storage は Cookie よりもはるかに大きな保存容量を持つため、Cookie の利用を改善する目的で作られました。ただし、それぞれの保存方法には異なる利点と欠点があります。   Web Storage: LocalStorage ローカルの Web storage に保存されたデータは永続的です。つまり、明示的に削除されない限り保持されます。プロジェクトの要件によっては、これは利点となり得ます。しかし、LocalStorage を使用する際は注意が必要です。保存したデータへの変更や追加は、該当のウェブページへの将来のすべての訪問時に利用可能になるためです。通常、LocalStorage の使用はあまり推奨しませんが、例外が存在する場合もあります。LocalStorage は同一オリジンポリシーをサポートしており、ここに保存されたすべてのデータは同一オリジンからのみ利用できます。さらに、LocalStorage を使用すると、あらゆる HTTP リクエストごとにデータをサーバーへ送信する必要がないため、クライアントとサーバー間のトラフィックが減少するというパフォーマンス上の利点もあります。   Web Storage: SessionStorage SessionStorage は LocalStorage に似ていますが、決定的な違いは永続的ではないことです。SessionStorage に書き込みを行ったウィンドウ（またはブラウザによってはタブ）を閉じると、データは失われます。これは、ユーザーセッション内でトークンへの読み取りアクセスを制限するのに有用です。セキュリティの観点では、通常は LocalStorage よりも SessionStorage の使用が望ましいといえます。LocalStorage と同様に、同一オリジンポリシーのサポートやクライアントとサーバー間のトラフィックの減少といった利点は SessionStorage にも当てはまります。   Cookies Cookie はセッションデータを保存する、より伝統的な方法です。各 Cookie に有効期限を設定でき、失効やアクセス制限を容易に行えます。しかし、Cookie を使用すると、すべての HTTP リクエストでデータがサーバーに送信されるため、クライアントとサーバー間のトラフィックは確実に増加します。Cookie を使用する場合は、セッションハイジャックへの対策が必要です。デフォルトでは、Cookie は HTTP 上で平文として送信されるため、内容がパケットスニッフィングや中間者攻撃（攻撃者がトラフィックを改ざんし得る状況）に対して脆弱になります。転送中のデータを保護するため、常に HTTPS を強制すべきです。これにより、機密性、完全性（データの）、および認証が提供されます。ただし、Web アプリケーションやサイトが HTTP と HTTPS の両方で利用可能な場合は、Cookie に「Secure」フラグを使用することも推奨されます。これにより、攻撃者がユーザーに対してサイトの HTTP 版へのリンクを送信し、その結果生成される HTTP リクエストを傍受することを防げます。 Cookie 使用時のセッションハイジャックに対する二次的な防御策としては、高影響の操作を実行する前にユーザーの本人確認を再度行うことが挙げられます。Cookie のセキュリティを強化するために検討すべきもう 1 つのフラグは「HttpOnly」フラグです。このフラグは、当該 Cookie がサーバー側からのみアクセス可能であるようにブラウザへ指示します。クライアントサイドのスクリプトによるアクセス試行はこのフラグによって禁止されるため、ほとんどのクロスサイトスクリプティング（XSS）攻撃に対する保護に役立ちます。