Firexport / Blog

Les erreurs App Check surviennent à l’une de deux étapes : quand l’application obtient un jeton auprès de son fournisseur d’attestation (Play Integrity, App Attest, reCAPTCHA), ou quand un service Firebase vérifie ce jeton. Si la première étape échoue, la seconde échoue aussi : ne vous arrêtez donc pas à l’erreur du service, cherchez d’abord l’erreur d’échange de jetons et corrigez les valeurs enregistrées pour votre plateforme. Les émulateurs, les simulateurs et localhost ne peuvent pas, par nature, passer l’attestation : ils utilisent un jeton de débogage.

Trouver l’étape en échec d’après le message

Faute de jeton, les requêtes adressées au service ne portent aucun jeton valide (le SDK Web joint à la place un jeton factice). Même si l’erreur visible vient du service, vérifiez donc d’abord si une erreur d’obtention du jeton apparaît aussi dans les journaux. Après un échec, le SDK attend avant de réessayer : sur le web, 24 heures après une erreur 403 ou 404 ; sur Android et Apple, 24 heures après une erreur 400 ou 404 ; et jusqu’à 4 heures après les autres erreurs. Cet état ne vit qu’en mémoire : après avoir corrigé la configuration, redémarrez l’application ou rechargez la page avant de vérifier.

Un jeton de débogage pendant le développement

Les émulateurs et les simulateurs ne sont pas reconnus comme des appareils valides, et les builds de débogage qui ne sont pas sur Google Play ne passent pas Play Integrity. Par principe, on n’ajoute pas localhost à une clé reCAPTCHA. Dans ces environnements, activez le fournisseur de débogage et enregistrez dans la console le jeton qu’il écrit dans les journaux.

1. N’activez le fournisseur de débogage que dans les builds de développement.

   // Android (Kotlin): com.google.firebase:firebase-appcheck-debug
   Firebase.appCheck.installAppCheckProviderFactory(
       if (BuildConfig.DEBUG) DebugAppCheckProviderFactory.getInstance()
       else PlayIntegrityAppCheckProviderFactory.getInstance(),
   )
   
   // iOS (Swift): before FirebaseApp.configure()
   #if DEBUG
   AppCheck.setAppCheckProviderFactory(AppCheckDebugProviderFactory())
   #endif
   
   // Web: before initializeAppCheck(), in development builds only
   self.FIREBASE_APPCHECK_DEBUG_TOKEN = true;
   
   // Flutter (firebase_app_check 0.5+)
   await FirebaseAppCheck.instance.activate(
     providerAndroid: kDebugMode
         ? const AndroidDebugProvider()
         : const AndroidPlayIntegrityProvider(),
     providerApple: kDebugMode
         ? const AppleDebugProvider()
         : const AppleAppAttestWithDeviceCheckFallbackProvider(),
   );

2. Lancez l’application et cherchez le jeton de débogage dans les journaux. Les SDK récents l’affichent sous la forme Firebase App Check debug token: <UUID> (dans logcat sur Android, la console Xcode sur Apple, la console du navigateur sur le web).
3. Enregistrez le jeton. Dans la console Firebase, ouvrez l’onglet Applications (Apps) d’App Check, puis choisissez Gérer les jetons de débogage (Manage debug tokens) dans le menu ⋮ de l’application. Chaque application peut en avoir jusqu’à 20.

• Les jetons changent. Un nouveau jeton est créé sur Android quand vous effacez les données de l’application ou la réinstallez, sur Apple quand vous la réinstallez, et sur le web quand vous utilisez un autre profil de navigateur ou effacez les données du site. Le nouveau jeton doit être enregistré à son tour.
• En CI, transmettez un jeton déjà enregistré. Sur le web, la chaîne du jeton dans self.FIREBASE_APPCHECK_DEBUG_TOKEN ; sur Android, l’argument d’instrumentation firebaseAppCheckDebugSecret ; sur Apple, la variable d’environnement du schéma AppCheckDebugToken ; dans Flutter, le paramètre debugToken.
• Traitez le jeton comme un mot de passe. Ne le mettez pas dans le dépôt, et gardez le fournisseur de débogage et son jeton hors des builds de production.

Causes par plateforme

Android (Play Integrity)

Apple (App Attest, DeviceCheck)

Web (reCAPTCHA)

AI Logic : App Check appliqué automatiquement depuis le 2 novembre 2026

Depuis le 2 novembre 2026, Firebase applique automatiquement App Check à Firebase AI Logic dans les projets qui ne l’appliquaient pas. Les requêtes sans jeton valide sont bloquées, de même que celles des versions de l’application publiées sans App Check. Deux erreurs d’AI Logic mentionnent App Check.

403 PERMISSION_DENIED: To access this model, you must enforce
Firebase App Check.

403 PERMISSION_DENIED: Firebase AI Logic has been deactivated in this
project. To resume using Firebase AI Logic, you must enforce Firebase
App Check.

• La première signifie qu’une requête sans jeton App Check valide a appelé un modèle qui fait souvent l’objet d’abus. Configurez App Check et appliquez-le. Pendant le développement, utilisez le fournisseur de débogage.
• La seconde signifie que le projet a été jugé inactif et n’applique pas App Check. Si vous l’appliquez déjà et que l’erreur apparaît quand même, vérifiez la protection contre la relecture (replay protection) : quand elle est activée, y compris en mode Monitor only, seuls les jetons à usage limité (limited-use tokens) sont acceptés.

Si des versions sans App Check sont encore entre les mains des utilisateurs, vous pouvez repousser la date à laquelle App Check est appliqué. Il suffit de changer la date du sélecteur Applique (Enforces) sur la ligne Firebase AI Logic de l’onglet API (APIs) d’App Check ; le 21 janvier 2027 est la dernière date possible. Si la ligne indique déjà Appliqué (Enforced), changez la date, puis, dans Configurer (Set up) sur cette ligne, passez la Protection de référence (Baseline protection) à Unenforced (monitoring only) et la protection contre la relecture à Disabled : ce n’est qu’ainsi qu’App Check cesse d’être appliqué. Google le déconseille : publiez donc avant cette date une version qui intègre App Check.

Avant de l’appliquer à d’autres services

• Regardez d’abord les métriques. L’onglet API (APIs) d’App Check répartit les requêtes de chaque service en requêtes validées (Verified), de clients obsolètes (Outdated client, sans jeton), d’origine inconnue (Unknown origin) et non valides (Invalid). Une fois App Check appliqué, seules les requêtes validées passent : appliquez-le quand presque toutes les requêtes récentes sont validées.
• Les anciennes versions de l’application sont bloquées. Les versions sans le SDK App Check voient leurs requêtes refusées dès que vous appliquez App Check.
• La prise d’effet peut prendre jusqu’à 15 minutes. Ne jugez pas le résultat dès qu’App Check est appliqué.
• Dans Cloud Functions, App Check ne peut être appliqué qu’aux fonctions appelables. Ajoutez enforceAppCheck: true et redéployez pour que cela prenne effet. App Check ne peut pas être appliqué aux fonctions onRequest : vérifiez-y vous-même le jeton avec l’Admin SDK.

Sources

• Présentation d’App Check, activer l’application d’App Check, surveiller les métriques, limite de jetons de débogage (REST)
• Fournisseur Play Integrity, quota Play Integrity, fournisseur de débogage pour Android
• Fournisseur App Attest, fournisseur DeviceCheck, fournisseur de débogage pour Apple, environnement App Attest (Apple), où App Attest est disponible (Apple)
• Fournisseur reCAPTCHA Enterprise, fournisseur reCAPTCHA v3, créer une clé reCAPTCHA, fournisseur de débogage pour le web
• Fournisseur de débogage pour Flutter, activate() dans firebase_app_check
• App Check pour AI Logic, codes d’erreur d’AI Logic, App Check pour Cloud Functions, vérifier les jetons dans votre propre backend
• Code source des SDK : limitation des tentatives sur le web, jeton factice sur le web, refus de Storage, message d’erreur Android, nouvelles tentatives sur Android, nouvelles tentatives sur Apple, refus des fonctions appelables