Présentation de l'API Play Integrity

L'API Play Integrity vous aide à vérifier que les actions des utilisateurs et les requêtes de serveur proviennent de votre application authentique, installée par Google Play et exécutée sur un appareil Android authentique et certifié. En détectant les interactions risquées (comme celles provenant de versions d'application falsifiées, d'appareils non fiables ou d'environnements émulés), votre serveur backend peut réagir en prenant les mesures appropriées pour empêcher les abus et les accès non autorisés, lutter contre la fraude et la tricherie, et protéger les utilisateurs contre les attaques.

L'API renvoie des évaluations qui vous aident à détecter les menaces potentielles, y compris :

• Accès non autorisé : l'évaluation accountDetails vous aide à déterminer si l'utilisateur a installé ou payé votre application ou votre jeu à partir de Google Play.
• Falsification de code : l'évaluation appIntegrity vous aide à déterminer si vous interagissez avec votre binaire non modifié reconnu par Google Play.
• Appareils à risque et environnements émulés : l'évaluation deviceIntegrity vous aide à déterminer si votre application s'exécute sur un appareil Android certifié authentique ou sur une instance authentique de Google Play Jeux pour PC.

Important : Lorsque l'API Play Integrity évalue un environnement, elle utilise des signaux de sécurité intégrés au matériel qui sont très résistants aux attaques et aux contournements. L'API Play Integrity simplifie le travail d'intégration et la gestion continue des développeurs en éliminant la complexité des signaux et en atténuant les problèmes sur les différentes versions du SDK Android, les clés provisionnées par les fabricants d'appareils et les modèles d'appareils.

Les développeurs Google Play peuvent également choisir de recevoir des évaluations supplémentaires pour détecter un plus large éventail de menaces potentielles, y compris :

• Appareils non corrigés : la réponse MEETS_STRONG_INTEGRITY dans l'évaluation deviceIntegrity vous aide à déterminer si un appareil a appliqué les mises à jour de sécurité récentes (pour les appareils exécutant Android 13 ou version ultérieure).
• Accès risqué par d'autres applications : l'évaluation appAccessRiskVerdict vous aide à déterminer si des applications en cours d'exécution peuvent être utilisées pour effectuer des captures d'écran, afficher des superpositions ou contrôler l'appareil (par exemple, en utilisant de manière abusive l'autorisation d'accessibilité).
• Logiciel malveillant connu : l'évaluation playProtectVerdict vous aide à déterminer si Google Play Protect est activé et s'il a détecté des applications douteuses ou dangereuses installées sur l'appareil.
• Hyperactivité : le niveau recentDeviceActivity vous aide à déterminer si un appareil a effectué un volume anormalement élevé de requêtes récemment, ce qui pourrait indiquer un trafic automatisé et un signe d'attaque.
• Utilisation abusive répétée et appareils réutilisés : deviceRecall (bêta) vous aide à déterminer si vous interagissez avec un appareil que vous avez déjà signalé, même si votre application a été réinstallée ou si l'appareil a été réinitialisé.

L'API peut être utilisée sur les facteurs de forme Android, y compris les téléphones, les tablettes, les appareils pliables, Android Auto, Android TV, Android XR, ChromeOS, Wear OS et Google Play Games pour PC.

Points à noter concernant la sécurité

L'API Play Integrity offre des avantages sans égal pour votre application lorsque vous suivez les pratiques recommandées :

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 plutôt 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. Par défaut, votre application peut effectuer jusqu'à 10 000 requêtes classiques par jour pour toutes les installations. Vous pouvez demander à augmenter votre limite quotidienne maximale.

Collecter des données télémétriques et cerner votre audience avant d'agir

Avant de modifier le comportement de votre application en fonction des évaluations de l'API Play Integrity, vous pouvez comprendre la situation actuelle de votre audience existante en implémentant l'API sans mesure d'application forcée. Une fois que vous avez obtenu l'évaluation que votre nombre d'installations actuel renvoie, vous pouvez estimer l'impact de toute mesure d'application envisagée et adapter votre stratégie de lutte contre les utilisations abusives en conséquence.

Décider de comment demander les évaluations de l'intégrité

L'API Play Integrity propose deux options pour demander et recevoir des évaluations de l'intégrité. Que vous effectuiez des requêtes standards ou classiques, ou une combinaison des deux, la réponse de l'évaluation de l'intégrité est renvoyée au même format.

Les requêtes API standards conviennent à tous les jeux et applications, et peuvent être effectuées à la demande pour vérifier que toute action de l'utilisateur ou requête du serveur est authentique. Elles présentent la latence la plus faible (quelques centaines de millisecondes en moyenne) et une haute fiabilité d'obtention d'une évaluation utilisable. Les requêtes standards utilisent la mise en cache intelligente sur l'appareil tout en déléguant à Google Play une protection contre certains types d'attaques.

Les requêtes API classiques, avec lesquelles les évaluations de l'intégrité étaient demandées à l'origine, restent également disponibles. Elles ont une latence plus élevée (quelques secondes en moyenne), et vous êtes responsable de l'atténuation des risques liés à certains types d'attaques. Les requêtes classiques consomment plus de données et de batterie que les requêtes standards, car elles lancent une nouvelle évaluation. Elles doivent donc être effectuées à titre exceptionnel pour vérifier si une action hautement sensible ou à forte valeur ajoutée est authentique. Si vous envisagez d'exécuter une requête classique et de la mettre en cache pour l'utiliser ultérieurement, il est conseillé d'effectuer une requête standard afin de réduire le risque d'attaque.

Le tableau suivant met en évidence quelques différences majeures entre ces deux types de requêtes :

	Requête API standard	Requête API classique
SDK Android minimal requis*	Android 6.0 (niveau d'API 23) ou version ultérieure	Android 6.0 (niveau d'API 23) ou version ultérieure
Préparation de l'API requise	✔️ (quelques secondes)	❌
Latence habituelle des requêtes	Quelques centaines de millisecondes	Quelques secondes
Fréquence des requêtes potentielles	Fréquentes (vérification à la demande pour toute action ou requête)	Occasionnelles (vérification ponctuelle des actions les plus intéressantes ou des requêtes les plus sensibles)
Atténuer les risques de rejeu et d'attaques similaires	Atténuation automatique par Google Play	Utiliser le champ nonce avec la logique côté serveur

* Pour la bibliothèque de l'API Play Integrity v1.4.0 et versions ultérieures, le SDK Android minimal compatible est le même pour les deux types de requêtes et est déterminé par le minSdkVersion de la bibliothèque. Pour la version 1.3.0 et les versions antérieures, le SDK Android minimal requis est Android 5.0 (niveau d'API 21) pour les requêtes API standards et Android 4.4 (niveau d'API 19) pour les requêtes API classiques.

Vous trouverez un tableau présentant d'autres différences dans les considérations relatives aux requêtes classiques.

Demander une évaluation de l'intégrité au moment opportun

Demandez une évaluation du risque d'accès à l'application très rapidement après l'action ou la requête de serveur à laquelle vous souhaitez empêcher l'accès, afin d'empêcher les escrocs de contourner la vérification de l'intégrité effectuée par votre application.

Rendre les requêtes API difficiles à répliquer

Les requêtes API standards comportent un champ nommé requestHash qui protège les utilisateurs contre les accès non autorisés et les attaques similaires. Dans ce champ, vous devez inclure un récapitulatif de toutes les valeurs pertinentes de la requête de votre application. Suivez les instructions sur l'utilisation de la liaison de contenu pour protéger les requêtes standards de votre application.

Les requêtes API classiques comportent un champ appelé nonce qui sert à protéger certains types d'attaques, tels que les attaques par relecture et la falsification. Suivez les conseils sur la génération des nonces pour protéger les requêtes classiques de votre application.

Attention : Les données que vous utilisez pour les champs requestHash et nonce sont visibles en texte clair par votre application et par Google. Vous devez chiffrer ou hacher les données avant de les transmettre à l'API Play Integrity.

Éviter la mise en cache des évaluations de l'intégrité

La mise en cache des évaluations de l'intégrité augmente le risque de proxying, qui constitue une attaque par laquelle un acteur malintentionné réutilise l'évaluation d'un bon appareil à des fins abusives dans un autre environnement. Plutôt que de mettre en cache les réponses, vous pouvez effectuer une requête API standard pour obtenir une évaluation à la demande.

Adopter une stratégie d'application à plusieurs niveaux

L'évaluation de l'intégrité de l'API Play Integrity offre un éventail de réponses possibles, ce qui permet de créer une stratégie de lutte contre les utilisations abusives avec plusieurs niveaux d'application. Pour ce faire, configurez le serveur backend de votre application de sorte qu'il se comporte différemment en fonction de chaque réponse ou groupe de réponses possible.

Avant d'évaluer la fiabilité de l'appareil, il est essentiel de vérifier les autres signaux principaux de la réponse de l'API :

• Détails de la requête : assurez-vous que les requestDetails correspondent aux valeurs attendues, en vérifiant en particulier les requestHash ou nonce pour éviter les attaques par rejeu.
• Intégrité de l'application : vérifiez que appRecognitionVerdict est défini sur PLAY_RECOGNIZED, ce qui confirme que le certificat de signature de l'application est reconnu par Play et n'a pas été modifié.
• Détails du compte : vérifiez que appLicensingVerdict est défini sur LICENSED, ce qui confirme que l'utilisateur a installé ou mis à jour l'application depuis Google Play.

Votre application doit pouvoir gérer les échecs de ces vérifications de référence, par exemple en utilisant la boîte de dialogue de correction Play intégrée. De plus, votre application doit également être capable de gérer les codes d'erreur qui peuvent survenir pendant la requête.

Une fois les vérifications de base effectuées, vous pouvez hiérarchiser votre stratégie d'application en fonction de la fiabilité des appareils en activant la réception de libellés d'appareil supplémentaires dans la réponse de l'API à partir de la Play Console. Chaque appareil renvoie tous les libellés dont il répond aux critères. Pour obtenir la version du SDK Android, vous devez utiliser le champ deviceAttributes inclus dans la réponse de l'API. Les niveaux de confiance des appareils vont des appareils les plus fiables aux moins fiables :

• MEETS_STRONG_INTEGRITY (Android 13 ou version ultérieure) : niveau de confiance le plus élevé de l'appareil, nécessitant des signaux de sécurité intégrés au matériel et un correctif de sécurité récent.
• MEETS_DEVICE_INTEGRITY (Android 13 ou version ultérieure) et MEETS_STRONG_INTEGRITY (versions antérieures à Android 13) : niveau de confiance suivant. Tous deux s'appuient sur des signaux de sécurité matériels.
• MEETS_DEVICE_INTEGRITY (versions antérieures à Android 13) : niveau suivant, qui utilise l'attestation basée sur le matériel lorsqu'elle est disponible et l'attestation basée sur le logiciel comme solution de secours.
• MEETS_BASIC_INTEGRITY : niveau de confiance le plus faible, juste avant de ne recevoir aucune étiquette d'appareil.

Par exemple, après avoir activé la réception de tous les libellés d'appareil, vous pouvez choisir de faire confiance à un appareil qui renvoie MEETS_STRONG_INTEGRITY, MEETS_DEVICE_INTEGRITY et MEETS_BASIC_INTEGRITY plus qu'à un appareil qui ne renvoie que MEETS_BASIC_INTEGRITY. Vous pouvez répondre différemment du serveur dans chaque scénario.

Vous pouvez ensuite ajouter d'autres signaux à votre stratégie d'application à plusieurs niveaux, par exemple en considérant comme moins fiables les appareils qui renvoient des niveaux plus élevés dans recentDeviceActivity.

Conseil : Les niveaux de confiance les plus élevés comptent moins d'appareils que les niveaux de confiance les plus bas. Il est donc recommandé d'adopter une stratégie d'application par niveaux plutôt que de s'appuyer uniquement sur les niveaux de confiance les plus élevés pour maximiser la couverture utilisateur.

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

Il est plus difficile de répliquer une plage de résultats que de renvoyer une réponse binaire (réussite/échec) du serveur à l'application. 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 CAPTCHA" et "Refuser", par exemple).

Détectez les abus répétés à l'aide du rappel de données appareil, tout en préservant la confidentialité des utilisateurs

Le rappel de données appareil permet aux applications de stocker et de rappeler des données personnalisées associées à un appareil spécifique, tout en préservant la confidentialité de l'utilisateur. Les données étant stockées sur les serveurs Google, votre appli peut les rappeler par appareil de manière fiable, même après sa réinstallation ou la réinitialisation de l'appareil. Vous disposez ainsi d'un moyen fiable de réidentifier un appareil que vous avez trouvé abusif par le passé, afin de prendre des mesures et d'empêcher qu'il ne soit à nouveau utilisé de manière abusive. Vous pouvez définir votre propre signification pour les trois valeurs qui composent les données de rappel de données appareil :

• Vous pouvez les utiliser comme trois options ou booléens distincts. Par exemple, les valeurs peuvent indiquer si un appareil a créé un compte ou non, s'il a utilisé un essai sans frais ou non, ou s'il a été identifié comme ayant commis un abus de gravité élevée ou non.
• Vous pouvez également combiner tous les états des valeurs dans un maximum de huit étiquettes personnalisées, par exemple une étiquette pour l'état par défaut lorsque les trois valeurs ne sont pas modifiées et sept étiquettes avec des significations personnalisées. Cela vous permet de segmenter tous les appareils en huit groupes maximum en fonction des comportements ou des actions que vous définissez. Dans ce scénario, la plus récente des trois valeurs writeDates indique la date de la dernière mise à jour de l'étiquette.

Gardez également à l'esprit les conditions préalables et autres considérations lorsque vous utilisez les données de rappel de données appareil.

Détecter les utilisations abusives à grande échelle à l'aide de l'activité récente de l'appareil

Dans l'API Play Integrity, utilisez la fonctionnalité activité récente de l'appareil afin de rechercher les appareils qui demandent un grand nombre de jetons d'intégrité. Les utilisateurs au comportement généralement abusif génèrent des résultats d'attestation valides à partir d'appareils réels et les fournissent aux bots dans le but de lancer des attaques automatisées sur les appareils en mode root ainsi que les émulateurs. Vous pouvez utiliser le niveau d'activité récente de l'appareil pour vérifier le nombre d'attestations générées par votre appli sur cet appareil au cours de la dernière heure.

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.

Anticiper les problèmes ou pannes inattendus

Le tableau de bord d'état de Play affiche des informations sur l'état de fonctionnement de l'API Play Integrity, ainsi que sur les perturbations et les pannes. Vous devez planifier à l'avance la manière dont votre serveur backend devra fonctionner dans l'éventualité peu probable d'une indisponibilité à grande échelle de l'API Play Integrity. Notez que votre serveur backend doit également être prêt à fonctionner si les clés d'attestation de clé de plate-forme Android spécifiques aux appareils sont révoquées.

Lutter contre la fraude à l'aide des solutions reCAPTCHA Enterprise de bout en bout

Les entreprises clientes à la recherche d'une solution complète de lutte contre la fraude et les bots peuvent acheter reCAPTCHA Enterprise pour mobile. Cette application inclut des SDK pour Android qui fournissent aux développeurs des scores de risque de fraude. reCAPTCHA Enterprise inclut automatiquement les signaux de l'API Play Integrity et les combine aux signaux reCAPTCHA relatifs aux réseaux et aux applications, offrant ainsi une solution prête à l'emploi, fluide et invisible pour lutter contre la fraude. Elle peut également protéger les applications Android sur lesquelles l'API Play Integrity n'est pas disponible.

Vérifier la légitimité du trafic dangereux accédant à des fonctionnalités importantes ou sensibles

Identifiez les actions sensibles ou importantes dans votre application ou jeu pour vous protéger avec l'API Play Integrity, au lieu de refuser complètement l'accès. Si possible, vérifiez la légitimité du trafic dangereux avant de lui permettre d'accéder aux actions importantes. Par exemple, lorsque le risque d'accès à l'application indique qu'une application en cours d'exécution pourrait capturer l'écran, demandez à l'utilisateur de désactiver ou de désinstaller les applications qui peuvent capturer l'écran avant de lui permettre d'accéder à une fonctionnalité que vous souhaitez protéger.

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 attentivement 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 pratiques de collecte, de partage et de sécurité des données de leurs applications afin d'en tenir les utilisateurs informés. Pour découvrir comment remplir votre formulaire de données, consultez ces informations sur la manière dont l'API Play Integrity traite les données.