Présentation de l'API Play Integrity

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

L'API Play Integrity protège vos applications et vos jeux contre les interactions potentiellement dangereuses et frauduleuses, telles que la tricherie et l'accès non autorisé. Vous pouvez ainsi réagir en prenant les mesures appropriées pour empêcher les attaques et limiter les abus.

Lorsque votre application ou votre jeu est utilisé sur des appareils équipés d'Android 4.4 (niveau d'API 19) ou version ultérieure, l'API Play Integrity fournit une réponse signée et chiffrée qui inclut les informations suivantes :

  • Binaire d'application authentique : déterminez si vous interagissez avec le binaire non modifié reconnu par Google Play.
  • Installation Play authentique : déterminez si le compte utilisateur actuel dispose d'une licence, c'est-à-dire si l'utilisateur a installé ou payé votre application ou votre jeu à partir de Google Play.
  • Appareil Android authentique : indique si votre application fonctionne sur un appareil Android authentique optimisé par les services Google Play.

Conditions d'utilisation et sécurité des données

En accédant à l'API Play Integrity et en l'utilisant, vous en acceptez les Conditions d'utilisation. Veuillez lire et accepter l'ensemble des conditions d'utilisation et des règles applicables avant d'accéder à l'API.

Google Play dispose d'une section sur la sécurité des données qui permet aux développeurs de divulguer les approches adoptées dans leurs applications concernant la collecte, le partage et la sécurité des données. Pour vous aider à répondre aux exigences de sécurité des données, découvrez comment l'API Play Integrity traite les données.

Points à noter concernant la sécurité

Bien que l'API Play Integrity renforce la sécurité et protège contre les altérations, son efficacité est optimale si vous suivez les pratiques recommandées suivantes :

Appliquer une stratégie de lutte contre les abus

L'API Play Integrity fonctionne de manière optimale lorsqu'elle est combinée avec d'autres signaux dans votre stratégie globale de lutte contre les abus que lorsqu'elle est exécutée comme seul mécanisme de protection Utilisez cette API conjointement avec d'autres bonnes pratiques de sécurité adaptées à votre application.

Ne pas générer le jeton d'intégrité trop fréquemment

La génération d'un jeton d'intégrité utilise du temps, des données et de la batterie, et chaque application a un nombre maximal d'appels qu'elle peut passer par jour, tel que défini par son niveau d'utilisation. Par conséquent, réservez l'utilisation de l'API aux actions stratégiques peu fréquentes, qui font partie intégrante de l'expérience utilisateur, telles que l'authentification auprès d'un service ou la connexion à un serveur multijoueur. Évitez de l'appeler pour les actions dont la fréquence est élevée et qui offrent peu de valeur ajoutée. Par exemple, ne l'appelez pas à chaque fois que l'application passe au premier plan ni à un intervalle de quelques minutes en arrière-plan. Toute application effectuant trop d'appels d'API peut être limitée afin de protéger les utilisateurs contre les implémentations incorrectes.

Utiliser le champ "nonce" pour mieux protéger votre application

L'API Play Integrity offre un champ appelé nonce, qui peut être utilisé pour mieux protéger votre application contre certaines attaques, telles que les attaques par relecture et les attaques de type "person in the middle" (PITM). Elle renvoie la valeur que vous avez définie dans ce champ, dans la réponse d'intégrité signée. Pour protéger votre application contre les attaques, suivez attentivement les consignes de génération des nonces.

Utiliser un environnement de serveur sécurisé

Effectuez le déchiffrement et la validation dans un environnement de serveur sécurisé. Si votre application cliente révèle des détails de sécurité, un pirate informatique peut les extraire de votre fichier APK ou de votre dépôt, ce qui lui donne de précieuses informations sur votre application ou votre jeu.

Envoyer une plage de réponses de votre serveur à votre application

Plutôt que d'envoyer à chaque fois la même réponse binaire (réussite/échec) du serveur à l'application, il est préférable d'utiliser une plage de résultats, qui est plus difficile à répliquer. Par exemple, vous pouvez opter pour une série de réponses associées ("Autoriser", "Autoriser avec des limites", "Autoriser avec des limites après la confirmation du reCAPTCHA" et "Refuser", par exemple).

Adopter une stratégie d'application à plusieurs niveaux

Dans la Play Console, vous pouvez choisir de recevoir des libellés d'appareils supplémentaires, ce qui vous permet d'élaborer une stratégie de lutte contre les utilisations abusives avec plusieurs niveaux d'application. Dès lors que vous avez accepté de recevoir des libellés supplémentaires, la réponse sur l'intégrité de l'appareil inclut plusieurs libellés pour le même appareil, à condition que chacun des critères applicables aux libellés soit respecté. Vous pouvez ainsi préparer votre serveur backend à adopter un comportement différent selon l'éventail de réponses possibles.

Par exemple, un appareil qui renvoie MEETS_BASIC_INTEGRITY, MEETS_DEVICE_INTEGRITY et MEETS_STRONG_INTEGRITY peut être considéré comme plus sûr qu'un appareil qui ne renvoie que MEETS_BASIC_INTEGRITY. Vous pouvez configurer la réponse de votre serveur en conséquence. Ces libellés peuvent être associés à différentes actions pour déterminer si le compte utilisateur est LICENSED ou UNLICENSED.

Réessayer avec un intervalle exponentiel entre les tentatives

Les conditions environnementales, telles qu'une connexion Internet instable ou un appareil surchargé, peuvent entraîner l'échec des vérifications de l'intégrité de l'appareil. Par conséquent, aucun libellé n'est généré pour un appareil digne de confiance. Pour pallier ce problème, veillez à permettre les nouvelles tentatives avec un intervalle exponentiel entre chacune d'elles.

Afficher des messages d'erreur exploitables

Si possible, fournissez des messages d'erreur utiles qui indiquent à l'utilisateur ce qu'il peut faire pour résoudre un problème. Par exemple, vous pouvez lui suggérer de réessayer, d'activer sa connexion Internet ou de vérifier que son application Play Store est à jour.

Utilisation générale de l'API

Figure 1 : Schéma séquentiel illustrant la conception générale de l'API Play Integrity

Lorsque l'utilisateur effectue dans votre application une action à forte valeur ajoutée que vous souhaitez protéger à l'aide d'une vérification de l'intégrité, suivez ces étapes :

  1. Le backend côté serveur de votre application génère et envoie une valeur unique à la logique côté client. Les étapes restantes désignent cette logique comme étant votre "application".
  2. Votre application crée le nonce à partir de la valeur unique et du contenu de votre action à forte valeur ajoutée. Elle appelle ensuite l'API Play Integrity, et transmet le nonce.
  3. L'application reçoit un verdict signé et chiffré de l'API Play Integrity.
  4. L'application transmet le verdict signé et chiffré à son backend.
  5. Le backend de votre application envoie le résultat à un serveur Google Play. Le serveur Google Play déchiffre et vérifie le résultat, puis renvoie les résultats au backend de votre application.
  6. Le backend de votre application décide de la marche à suivre en fonction des signaux qui se trouvent dans la charge utile du jeton.
  7. Le backend de votre application envoie les résultats de la décision à votre application.

Niveaux d'utilisation de l'API

Les requêtes adressées à l'API sont soumises à un nombre maximal par application et par jour, qui est déterminé par le niveau d'utilisation attribué à l'application qui est à l'origine de l'appel. Le tableau suivant présente les différents niveaux :

Tableau 1. Niveaux d'utilisation de l'API Play Integrity
Niveau d'utilisation Nombre d'appels d'API autorisés par jour Critères d'éligibilité
Standard Jusqu'à 10 000 Disponible pour les applications utilisant tous les canaux de distribution
Supérieur Plus de 10 000 (sous réserve d'approbation) Doit implémenter correctement la logique d'API, y compris les nouvelles tentatives
Disponible pour les applications utilisant n'importe quel canal de distribution en plus de Google Play

Le même nom de package sur Google Play et sur les autres canaux de distribution est considéré comme une seule application en termes d'utilisation de l'API. Vous pouvez utiliser un seul ID de projet Google Cloud pour plusieurs applications avec des noms de package différents. Dans ce cas, les applications sont comptabilisées comme une seule application en termes d'utilisation de l'API.

Afficher votre niveau d'utilisation

Pour vous aider à évaluer la fréquence d'interaction avec l'API Play Integrity, la Play Console indique le niveau d'utilisation de votre application. Pour afficher ce niveau d'utilisation, procédez comme suit :

  1. Connectez-vous à la Play Console.
  2. Sélectionnez une application qui utilise l'API Play Integrity.
  3. Dans la section "Publier" du menu de gauche, accédez à Configuration > Intégrité de l'appli.
  4. Dans la section "Paramètres" de l'onglet "API Integrity", recherchez la propriété "Niveau d'utilisation". La valeur de cette propriété indique le niveau d'utilisation de votre application.

Modifier votre niveau d'utilisation

Pour demander la modification du niveau d'utilisation de votre application, remplissez ce formulaire. Demandez à passer au niveau d'utilisation supérieur si votre application doit gérer un plus grand nombre d'utilisateurs, mais n'appelez pas l'API plus souvent par utilisateur. Même avec un niveau d'utilisation élevé, votre application doit continuer à limiter les appels d'API aux actions peu fréquentes et à forte valeur ajoutée.

Configurer la surveillance des quotas et les alertes

Les demandes d'augmentation de niveau sont généralement traitées sous quelques jours ouvrés. Pour garantir une bonne expérience utilisateur et éviter les situations d'urgence, nous vous recommandons de configurer la surveillance et les alertes d'utilisation des quotas d'API de votre application avec Cloud Monitoring.