APIキーは、FirebaseやGoogleサービスとやり取りするときにリクエストをFirebaseプロジェクトにルーティングするために使用される一意の文字列です。このページでは、APIキーに関する基本情報と、FirebaseアプリでAPIキーを使用および管理するためのベストプラクティスについて説明します。
APIキーとFirebaseに関する一般情報
FirebaseのAPIキーは、通常のAPIキーとは異なります
APIキーが通常使用される方法とは異なり、FirebaseサービスのAPIキーは、バックエンドリソースへのアクセスを制御するために使用されません。これは、Firebaseセキュリティルール(リソースにアクセスできるユーザーを制御するため)とアプリチェック(リソースにアクセスできるアプリを制御するため)でのみ実行できます。
通常、APIキーをしっかりと保護する必要があります(たとえば、ボールトサービスを使用したり、キーを環境変数として設定したりします)。ただし、FirebaseサービスのAPIキーは、コードまたはチェックインされた設定ファイルに含めることができます。
FirebaseサービスのAPIキーはコードに安全に含めることができますが、APIキーに制限を適用する必要がある特定のケースがいくつかあります。たとえば、Firebase ML、メール/パスワードのログイン方法を使用したFirebase認証、または請求可能なGoogle CloudAPIを使用している場合です。これらのケースの詳細については、このページの後半でご覧ください。
APIキーの作成
Firebaseプロジェクトには多くのAPIキーを含めることができますが、各APIキーは単一のFirebaseプロジェクトにのみ関連付けることができます。
次のいずれかを実行すると、FirebaseはプロジェクトのAPIキーを自動的に作成します。
- Firebaseプロジェクトを作成する>自動作成された
Browser key
- FirebaseAppleアプリを作成>自動作成された
iOS key
- FirebaseAndroidアプリを作成>自動作成された
Android key
開発やデバッグなどのために、 Google CloudConsoleで独自のAPIキーを作成することもできます。これがいつ推奨されるかについては、このページの後半で詳しく説明します。
APIキーを見つける
プロジェクトのすべてのAPIキーは、Google CloudConsoleの[APIとサービス]> [認証情報]パネルで表示および管理できます。
また、次の場所で、どのAPIキーがFirebaseアプリに自動的に一致するかを確認できます。デフォルトでは、同じプラットフォーム(Apple対Android対Web)用のプロジェクトのすべてのFirebaseアプリが同じAPIキーを使用します。
Firebase Apple Apps
API_KEY
フィールドのFirebase設定ファイル
でアプリの自動一致APIキーを検索します。GoogleService-Info.plist Firebase Androidアプリ—Firebase設定ファイル
のgoogle-services.json current_key
フィールドでアプリの自動一致APIキーを検索します。Firebase Web Apps —Firebase構成オブジェクトの
apiKey
フィールドでアプリの自動一致APIキーを検索します。
APIキーの使用
APIキーは、Firebase / Googleサービスとやり取りするときにFirebaseプロジェクトを識別するために使用されます。具体的には、割り当てと請求のためにAPIリクエストをプロジェクトに関連付けるために使用されます。また、公開データへのアクセスにも役立ちます。
たとえば、APIキーの値をクエリパラメータとしてREST API呼び出しに渡すことにより、APIキーを明示的に使用できます。この例は、ダイナミックリンクリンク短縮APIにリクエストを送信する方法を示しています。
POST https://firebasedynamiclinks.googleapis.com/v1/shortLinks?key=API_KEY
アプリがFirebaseAPIを呼び出すと、アプリは自動的にFirebase構成ファイル/オブジェクトでプロジェクトのAPIキーを探します。ただし、環境変数など、別のメカニズムを使用してAPIキーを設定できます。
APIキーに制限を適用する(推奨)
FirebaseサービスのAPIキーをシークレットとして扱う必要はありませんが、APIキーの誤用からプロジェクトを保護するために、追加の対策を講じたい場合があります(以下を参照)。
パスワードベースの認証を使用する場合は、クォータを厳しくします
パスワードベースのFirebase認証を使用していて、誰かがAPIキーを入手した場合、 Firebaseセキュリティルールで保護されている限り、FirebaseプロジェクトのデータベースやCloudStorageデータにアクセスすることはできません。ただし、APIキーを使用して、Firebaseの認証エンドポイントにアクセスし、プロジェクトに対して認証リクエストを行うことができます。
誰かがAPIキーを悪用してブルートフォース攻撃を試みる可能性を軽減するために、アプリの通常のトラフィックの期待を反映するように、 identitytoolkit.googleapis.com
エンドポイントのデフォルトの割り当てを厳しくすることができます。この割り当てを厳しくし、アプリが突然ユーザーを獲得した場合、割り当てを増やすまでサインインエラーが発生する可能性があることに注意してください。 Google CloudConsoleでプロジェクトのAPI割り当てを変更できます。
特定のタイプのAPIには、個別の制限付きAPIキーを使用します
Firebaseサービスに使用されるAPIキーは通常、シークレットとして扱う必要はありませんが、手動で有効にしたGoogle CloudAPIへのアクセスを許可するために使用されるAPIキーには特別な注意を払う必要があります。
Firebaseによって自動的に有効にされない(つまり、自分で有効にした)Google Cloud APIを(任意のプラットフォームで)使用する場合は、それらのAPIで使用するための個別の制限付きAPIキーを作成することを検討する必要があります。 APIが請求可能なGoogleCloudサービス用である場合、これは特に重要です。
たとえば、iOSでFirebaseMLのCloudVision APIを使用する場合は、Cloud VisionAPIへのアクセスにのみ使用する個別のAPIキーを作成する必要があります。
Firebase以外のAPIに個別の制限付きAPIキーを使用することで、Firebaseサービスの使用を中断することなく、必要に応じてキーをローテーションまたは置換したり、APIキーに制限を追加したりできます。
これらの手順では、 Super Service API
ServiceAPIと呼ばれる偽のAPI用に個別の制限付きAPIキーを作成する方法について説明します。
ステップ1: Super Service API
へのアクセスを禁止するように既存のAPIキーを構成します
Google CloudConsoleの[認証情報]ページを開きます。プロンプトが表示されたら、プロジェクトを選択します。
リスト内の既存のAPIキーごとに、編集ビューを開きます。
[ APIの制限]セクションで、[キーの制限]を選択し、APIキーにアクセスを許可するすべてのAPIをリストに追加します。別のAPIキーを作成するAPI(この例では
Super Service API
)を含めないようにしてください。APIキーのAPI制限を構成する場合、キーがアクセスできるAPIを明示的に宣言しています。デフォルトでは、[ API制限]セクションで[キーを制限しない]が選択されている場合、APIキーを使用して、プロジェクトで有効になっている任意のAPIにアクセスできます。
これで、既存のAPIキーはSuper Service API
へのアクセスを許可しませんが、各キーは、 API制限リストに追加したすべてのAPIで引き続き機能します。
ステップ2: Super Service API
にアクセスするための新しいAPIキーを作成して使用する
[資格情報]ページに戻ります。 Firebaseプロジェクトがまだ選択されていることを確認してください。
[資格情報の作成]> [APIキー]をクリックします。新しいAPIキーをメモしてから、[キーを制限]をクリックします。
[ API制限]セクションで、[キーを制限]を選択し、
Super Service API
のみをリストに追加します。この新しいAPIキーは、
Super Service API
へのアクセスのみを許可します。新しいAPIキーを使用するようにアプリとサービスを構成します。
環境固有のAPIキーを使用する(推奨)
ステージングや本番環境など、環境ごとに異なるFirebaseプロジェクトを設定する場合は、各アプリインスタンスが対応するFirebaseプロジェクトとやり取りすることが重要です。たとえば、ステージングアプリインスタンスが本番Firebaseプロジェクトと通信しないようにする必要があります。これは、ステージングアプリがステージングFirebaseプロジェクトに関連付けられたAPIキーを使用する必要があることも意味します。
コード自体にAPIキーを含めるのではなく、開発からステージング、本番へのコード変更を促進する問題を減らすには、APIキーを環境変数として設定するか、構成ファイルに含めます。
FirebaseMLと一緒にFirebaseLocal Emulator Suiteを開発に使用している場合は、デバッグ専用のAPIキーを作成して使用する必要があることに注意してください。この種のキーを作成する手順は、 FirebaseMLのドキュメントに記載されています。
よくある質問
無効なAPIキーの最も一般的な原因のいくつかを次に示します。
APIキーには「APIキー制限」が適用されており、キーを使用しようとしているアプリとは一致しない(「アプリケーション制限」)か、呼び出されているAPIに使用できません(「API制限」)。
APIキーがGoogleCloudConsoleのプロジェクトから削除されました。
アプリのFirebase構成ファイル/オブジェクトにリストされているプロジェクトIDのAPIキーが作成されていません。
この問題を修正する1つの方法は、アプリのFirebase構成ファイル/オブジェクトの更新バージョンを取得してから、古い構成ファイル/オブジェクトを新しい更新されたファイル/オブジェクトに置き換えることです。ダウンロード用の設定ファイルを送信したり、コンソールに設定オブジェクトを表示したりする前に、FirebaseはリストされているAPIキーがアプリと一致することを確認します。
Webアプリで使用されるAPIキーには、おそらく「API制限」が適用されています。この場合は、Firebase ManagementAPIが許可されているAPIのリストに含まれていることを確認してください。
いいえ、APIキーは特定のプロジェクトのみを識別し、別のプロジェクトに移動することはできません。
アプリのFirebase設定ファイル/オブジェクトを最初に取得するときに、Firebaseは、アプリに一致する「アプリケーション制限」 (たとえば、Appleアプリの一致するバンドルID)を持つ既存のAPIキーがプロジェクトにあるかどうかを確認します。
一致する制限付きキーがFirebaseで見つからない場合は、構成ファイル/オブジェクトに、AppleアプリのiOS key
、AndroidアプリのAndroid key
、およびWebアプリのBrowser key
が一覧表示されます(これらのキーが存在し、それらがそのアプリと一致しないようにする「アプリケーション制限」はありません)。
はい、設定ファイル/オブジェクトからAPIキーを手動で削除できます。ただし、アプリがAPIキーにアクセスするには(環境変数などを介して)、他のメカニズムを提供する必要があります。そうしないと、Firebaseサービスへの呼び出しが失敗します。
はい、構成ファイル/オブジェクトを手動で編集して、別のAPIキーをアプリに関連付けることができます。
コンソールからアプリの設定ファイル/オブジェクトを再取得すると、 Firebaseがそのアプリと自動的に一致するAPIキーが常に一覧表示されることに注意してください。したがって、必要に応じて手動編集を繰り返す必要があります。
Firebase Apple Apps —各アプリには独自の設定ファイルがあり、リストできるAPIキーは1つだけです。
Firebase Androidアプリ— FirebaseプロジェクトのすべてのAndroidアプリは同じ設定ファイルに一覧表示され、各アプリに表示できるAPIキーは1つだけです。ただし、この構成ファイル内の各アプリには、異なるキーをリストすることができます。
Firebase Webアプリ—各アプリには独自の構成オブジェクトがあり、リストできるAPIキーは1つだけです。
ただし、1つのアプリで複数のAPIキーを使用できます。環境変数などを介して、アプリがこれらの他のAPIキーにアクセスするためのメカニズムを提供する必要があります。他のAPIキーにアクセスするメカニズムは、Firebase設定ファイル/オブジェクトにリストされているAPIキーに依存することはできません。
アプリで使用されているAPIキーを削除すると、そのアプリからのAPI呼び出しは失敗します。無効なAPIキーを使用しようとすると、レポート、電子メール、またはエラーが発生する可能性があります。
APIキーの削除は永続的であり、元に戻すことはできません。