FirebaseのApp Checkに関係して403が返っても、エラーだけで「App Checkが原因」とは断定できません。まず失敗したFirebase製品・APIと、開発端末か本番端末かを特定します。そのうえでApp Checkのリクエスト指標、アプリ登録、provider、token送信、enforcementを順に確認してください。Security Rulesを広げたり、App Checkを全体で無効にしたりするのは、原因を確認してからにします。
この記事はFirebaseプロジェクトを操作した実測記録ではなく、公式ドキュメントに基づく切り分け手順です。コンソールの値やアプリ固有の設定は、対象プロジェクトで確認してください。
目次
最初に「どの403か」を特定する
403は認可・検証失敗を示すHTTP応答ですが、App Check由来とは限りません。Firebase Authentication、Security Rules、IAM、APIの権限、独自バックエンドの検証なども候補です。App Checkの公式RESTメソッド projects.verifyAppCheckToken は、渡されたApp Check tokenが無効なら403を返します。しかし、この記述をFirestoreやStorageなどすべての403へ一般化してはいけません。
最初に、失敗したリクエストについて次を一枚に記録します。
-
呼び出したFirebase製品または自前API、操作名、時刻
-
対象Firebase project ID、Firebase app ID、環境（local・CI・staging・production）
-
クライアントSDKの種類とバージョン、OS・ブラウザ
-
App Checkを強制している対象サービスか、開発中か
-
返されたHTTP status、Firebase error code、レスポンス本文（tokenや個人情報は記録から除く）
-
失敗した一件の前後で成功する操作があるか
ここで重要なのは、アプリのFirebase設定に書かれたproject IDと、コンソールでApp Checkを設定したprojectが同じかを照合することです。同じFirebaseプロジェクト内でも、Android・Apple・Webのアプリ登録は別々です。別アプリ用に発行・登録したdebug tokenを、対象アプリのものとして扱わないでください。
App Check指標で状態を切り分ける
Firebase ConsoleのApp Checkで、失敗したサービスのリクエスト指標を確認します。指標はリクエストの分類であり、個々の失敗原因を一意に特定する診断ログではありません。時間帯、Firebase app、サービスをそろえて、失敗時刻付近に分類が変化しているかを見ます。
表は横にスクロールできます
| 指標の分類 | 公式説明に沿った意味 | 次に確認すること |
|---|---|---|
| Verified | 有効なApp Check tokenを持つリクエスト | アプリ操作自体の権限、Rules、IAM、API設定など別の拒否要因を調べる |
| Outdated client | tokenがないリクエスト。SDK導入前の古いアプリなどが候補 | App Check SDKの導入版、配布済みアプリの更新状況を確認する |
| Unknown origin | tokenがなく、Firebase SDK由来に見えないリクエスト | 呼び出し元、API keyの利用先、自前クライアントや不正リクエストの可能性を調べる |
| Invalid | 無効なtokenを持つリクエスト。偽装クライアントやエミュレーター環境などが候補 | provider、対象project/app、tokenの取得・送信、開発環境を照合する |
| Reused token | 以前使われたtokenの再使用 | Replay protectionの適用範囲と、同一tokenを複数リクエストへ使う実装かを確認する |
この分類だけで「debug token未登録」「アプリの不正」などと決めつけないでください。たとえばInvalidが増えていても、開発中のエミュレーターなのか、アプリの登録先がずれているのか、第三者のリクエストなのかを追加で確認します。指標が見えない場合は、サービスがApp Check指標に対応するか、プロジェクト・アプリ・対象期間が一致しているかを確認してください。
debug tokenを使うのは開発・テスト環境だけ
App Checkの実providerは、エミュレーター、localhost、CIなどを本番相当の検証済み端末として扱わない場合があります。そのため、公式Docsはdebug buildでdebug providerを使う方法を案内しています。debug providerは実端末のattestationを代替するテスト手段です。productionの保護を弱めるための回避策ではありません。
登録手順はplatform SDKごとに異なりますが、考え方は共通です。
-
Firebase Consoleで対象のFirebase appとApp Check provider設定を確認する。
-
localまたはCI専用のdebug buildで、そのplatform用debug providerを有効にする。
-
実行ログに表示されたdebug tokenを、対象projectの対象appへ登録する。
-
登録が反映された後、同じdebug buildから同じサービス操作を再試験する。
-
検証が終わったらdebug providerをproduction buildへ含めないことを、ビルド設定とリリース成果物で確認する。
表は横にスクロールできます
| Platform / 環境 | 確認の焦点 |
|---|---|
| Web | 正しいFirebase appへWeb debug providerを初期化したか。表示されたtokenを対象Web appへ登録したか。 |
| Android | 対象Android appでdebug providerを使うdebug buildか。ログに出たtokenを同じappへ登録したか。 |
| Apple platforms | 対象Apple appとdebug実行環境でproviderを切り替え、発行tokenを同じappへ登録したか。 |
| Flutter | 各platform向けprovider設定が、実行しているビルド種別と一致するか。Flutter一つの設定で全platformのproviderが自動的に同一になると考えない。 |
debug tokenは、検証環境を通すための秘密情報として扱います。公開リポジトリ、共有ログ、スクリーンショット、チケットへ値を貼らず、production buildにも同梱しません。漏えいした登録tokenはFirebase Consoleで削除し、必要な開発環境では新しいtokenを登録します。Debug tokenを登録すると、そのtokenを提示する未検証端末にも対象サービスへのアクセスが認められるため、登録先と利用者を限定してください。
production attestationで失敗する場合
本番アプリでは、対象platformとFirebase appに適した実providerを確認します。次の順番で、設定値と実行環境の組み合わせを照合します。
-
Projectとappの一致：アプリが初期化するFirebase project ID・app IDと、App Check Consoleで開いたproject・appが一致するか。
-
Providerの一致：Android、Apple、Webで選んだproviderが、アプリの実行環境およびFirebase側の登録と一致するか。
-
SDK初期化の順序：App Checkが対象Firebase SDKのリクエストより前に有効化されているか。製品別の公式手順と現在のSDKバージョンを確認する。
-
token取得と送信：該当サービスのFirebase SDK経由のリクエストか、自前APIへのリクエストかを区別する。自前APIでは、クライアントからApp Check tokenを送信し、バックエンドで検証する実装が必要になる場合がある。
-
配布状態：古いアプリ、異なるFirebase設定ファイル、別のbuild flavor、staging用の値がproductionへ混ざっていないか。
ここでの「一致」は原因を絞るための確認項目です。アプリの登録やprovider設定を変える前に、実際のエラーログと指標を照らし合わせてください。SDK設定を変更する場合は、検証用buildで再現を確認し、対象appと環境を限定します。
enforcementを変える前の確認
App Checkをenforceすると、対象Firebaseサービスは有効なApp Check tokenのないリクエストを拒否します。enforcementの変更は、403回避のために反射的に切り替える操作ではありません。公式Docsは、SDKを導入した後、強制前にリクエスト指標を確認して既存ユーザーへの影響を見積もるよう案内しています。enforcementを有効にした状態では、SDK未導入の古いクライアントが影響を受ける可能性があります。設定変更が反映されるまで時間がかかることもあるため、直後の一件だけで結果を判定しないでください。
本番で判断する場合は、少なくとも次を満たしてから担当者が変更計画を立てます。
-
対象サービスと対象Firebase appが明確
-
リクエスト指標の期間とアプリ配布バージョンを確認済み
-
正規クライアントのOutdated / Invalidリクエストが残っていないか確認済み
-
旧版アプリへの影響、問い合わせ対応、戻し方を整理済み
-
enforcement対象を限定し、変更後にメトリクスと実利用を監視できる
この記事の手順ではFirebase Consoleの設定を変更しません。アプリ利用者へ影響し得るenforcementの切替は、デバッグ目的の個別確認とは別のリリース判断として扱ってください。
自前バックエンドで検証する場合
Firestore等のFirebase SDKで保護されるサービスと、自分で運用するAPIでは、token確認の場所が異なります。自前APIをApp Checkで保護する場合は、クライアントからApp Check tokenを送信し、信頼できるバックエンドでFirebase Admin SDK等を使って検証します。公式のREST projects.verifyAppCheckToken を直接使う設計もありますが、無効tokenで403になるのはこの検証メソッド固有の説明です。利用前に、実装するAPIの認証方式、権限、provider対応、tokenの再使用・Replay protection要件を公式リファレンスで確認してください。
サーバーでApp Checkを導入しただけで、クライアントリクエストへtokenが自動付与されるわけではありません。また、通常のFirebase製品APIと自前APIで同じ検証コードが使えるとも限りません。まず該当APIの公式手順に従い、tokenをどのheaderまたはSDK経路で送るか、サーバー側でどのproject・appを許可するかを明確にします。秘密鍵やtoken値をログへ残さないよう、診断ログには検証結果・時刻・相関IDなど必要最小限を記録します。
症状から次の確認へ進む
表は横にスクロールできます
| 症状 | 優先する確認 | 変更を急がない理由 |
|---|---|---|
| local / emulatorだけ失敗する | debug build、debug provider、対象appへのtoken登録、Firebase Consoleの指標 | production providerやRulesを変えてもlocal環境の問題は解決しないことがある |
| 本番の一部ユーザーだけ失敗する | app version、project/app登録、provider、Outdated / Invalid指標 | enforcementを無効化すると、問題のない全ユーザーの保護まで弱める可能性がある |
| App Check指標はVerifiedだが操作が403 | Firebase製品のRules・Auth・IAM・API権限・独自backendを調べる | App Checkが通った後の別認可層で拒否されている可能性がある |
| 自前APIだけ失敗する | token送信、header、サーバー検証、許可するproject/app、API権限 | FirebaseのSDK管理サービスと異なり、サーバー側実装の確認が必要 |
| enforcement直後から失敗が増えた | 対象サービス・変更時刻・Outdated/Invalid指標・古いクライアント | 対象製品の未検証requestは拒否される。変更の影響範囲を確認してから戻すか判断する |
verifyAppCheckToken が403を返す | 送ったtokenの有効性、対象projectとの対応、provider対応 | このRESTメソッドでは無効tokenが403になる。サービス全般の原因とは限らない |
この表に当てはまらない場合は、エラー全文から秘密情報を除いて保存し、該当Firebase製品の公式トラブルシューティングへ進みます。App Checkの指標はrequestを分類する補助情報で、アプリのRules・認証・アプリ固有コードを置き換えるものではありません。
再試験と完了判定
修正を試す前に、1回のリクエストで何を確認するか決めます。たとえば「Web debug tokenを対象Web appへ登録した後、local buildからFirestoreの読み取りを一度実行し、該当時刻のApp Check指標でVerifiedへ移ったかを見る」のように、環境・操作・観察値を固定します。実施していない操作や成功していない結果を、確認済みの体験として扱わないでください。
再試験は、開発環境でdebug provider、本番環境で実providerを使い分けます。成功したら、対象project/app、build種別、SDK/provider、操作時刻、指標の変化、採った修正を記録します。失敗が続く場合は、その操作がApp Checkを使うFirebase製品か、自前APIか、あるいは別の権限層かをもう一度切り分けます。
安全のため、次の状態なら作業を止めて管理者へ戻します。
-
対象projectやappを特定できない
-
本番enforcementを変えないと試験できない
-
debug tokenの所有者・登録先が不明
-
失敗対象がApp Check対応サービスか確認できない
-
問題を解くためSecurity RulesやIAMを広げる必要があるが、必要な最小権限を説明できない
次にすること： まず失敗した一件のproject/app・サービス・環境・時刻を記録し、App Check request metricsで同じ時間帯を確認してください。Invalidならproviderとtoken経路、OutdatedならSDK導入状況、VerifiedならApp Check以外の権限層へ進みます。本番設定は指標と影響範囲を確認してから別途判断します。
参考資料
Evidence checked: 2026-10-15. Project-specific Firebase configuration, user error logs, and App Check metrics were not accessed. Source of Truth: current Writing / Editorial guidelines verified earlier in this sprint.