最高の実践

API Key とキーおよびトークンは厳重に保護する必要があります。 

これらの認証情報は、あなたの開発者用 Appおよび、あなたが代理でリクエスト送信を許可した X アカウントに直接ひも付いています。キーが漏えいした場合、不正利用者がそれらを用いて、あなたの開発者用 App またはその承認済みユーザーの代理として X の endpoint にリクエストを送信し、その結果、予期しないレートリミットに達したり、有料アクセスの割り当てを使い切ったり、さらには開発者用 App が停止される可能性もあります。

以下のセクションでは、API Key とキーおよびトークンを管理する際に考慮すべきベストプラクティスを示します。

​

API キーおよびトークンの再生成

API キーが漏えいした可能性がある場合は、次の手順に従って API キーを再生成してください。

1. developer portal の「Projects and Apps」ページに移動します。
2. 対象の App の横にある「Keys and tokens」アイコン（🗝）をクリックします。
3. 再生成したいキーおよびトークンのセットの横にある「Regenerate」ボタンをクリックします。 

Access Tokens または Bearer Tokens をプログラムで再生成する場合は、認証 endpoint を使用して実行できます。

• Access Tokens を再生成する場合は、POST oauth/invalidate_token endpoint でトークンを無効化し、その後 3-legged OAuth フローでトークンを再生成してください。
• Bearer Token を再生成する場合は、POST oauth2/invalidate_token endpoint でトークンを無効化し、その後 POST oauth2/token endpoint でトークンを再生成してください。

​

シークレットを一元管理するファイルを用意する

シークレットを格納するために、.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 Key や キーおよびトークン を含むソースコードをコミットしてしまうことです。これらのリポジトリの多くは公開されています。公開リポジトリでこのミスがあまりに頻繁に起きるため、API Key をスクレイピングする収益目的のボットまで存在します。

• サーバーの環境変数を使用する。API Key を環境変数に保存すれば、コードやバージョン管理から切り離せます。これにより、環境ごとに異なるキーを容易に使い分けることもできます。
• ソース管理から除外した設定ファイルを使用する。ファイルをバージョン管理の追跡対象から外すために、ファイル名を .gitignore に追加します。
• バージョン管理を使った後にコードから API Key を削除しても、コードベースの過去バージョンを参照すれば API Key に依然としてアクセスできる可能性があります。次のセクションで説明するように、API Key を再生成してください。

​

データベース

access token をデータベースに保存する必要がある場合は、次の点に留意してください。

• access token がその所有者のみ読み取れるよう、データベースへのアクセスを制限してください。
• access token 用のデータベーステーブルに対する編集／書き込み権限を制限してください。これはキー管理システムで自動化されている必要があります。
• いかなる data ストアに保存する場合も、事前に access token を暗号化してください。

​

パスワード管理ツール

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

​

Web storage & cookies

Web Storage には LocalStorage と SessionStorage の2種類があります。Cookie よりはるかに大容量を扱えるため、Cookie の利用に対する改良として設計されました。ただし、それぞれの保存方式には異なる長所と短所があります。  

Web Storage: LocalStorage

ローカルの Web Storage に保存された内容は永続的です。つまり、明示的に削除されるまで保持されます。Project の要件によっては利点となり得ますが、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）攻撃に対する防御に役立ちます。