Panoramica dell'API Play Integrity

L'API Play Integrity ti aiuta a verificare che le azioni degli utenti e le richieste del server provengano dalla tua app originale, installata da Google Play ed eseguita su un dispositivo Android originale e certificato. Rilevando interazioni rischiose, come quelle provenienti da versioni dell'app manomesse, dispositivi non attendibili o ambienti emulati, il tuo server di backend può rispondere con azioni appropriate per prevenire abusi e accessi non autorizzati, combattere le frodi, contrastare gli imbrogli e proteggere gli utenti dagli attacchi.

L'API restituisce esiti che ti aiutano a rilevare potenziali minacce, tra cui:

• Accesso non autorizzato: l'esito accountDetails ti aiuta a stabilire se l'utente ha installato o pagato la tua app o il tuo gioco su Google Play.
• Manomissione del codice: l'esito appIntegrity ti aiuta a stabilire se stai interagendo o meno con il tuo file binario non modificato riconosciuto da Google Play.
• Dispositivi rischiosi e ambienti emulati: l'esito deviceIntegrity ti aiuta a determinare se la tua app è in esecuzione su un dispositivo Android originale certificato o su un'istanza originale di Google Play Games per PC.

Punto chiave: quando l'API Play Integrity valuta un ambiente, utilizza indicatori sicuri basati sulla crittografia hardware altamente resilienti ad attacchi e aggiramenti. L'API Play Integrity semplifica il lavoro di integrazione e la gestione continua degli sviluppatori eliminando la complessità dei segnali e la mitigazione dei problemi nelle varie versioni dell'SDK Android, nelle chiavi fornite dal produttore del dispositivo e nei modelli di dispositivo.

Gli sviluppatori di Google Play possono anche attivare la ricezione di esiti aggiuntivi per rilevare una gamma più ampia di potenziali minacce, tra cui:

• Dispositivi senza patch. La risposta MEETS_STRONG_INTEGRITY nell'esito deviceIntegrity ti aiuta a determinare se un dispositivo ha applicato aggiornamenti della sicurezza recenti (per i dispositivi con Android 13 e versioni successive).
• Accesso rischioso da parte di altre app. L'esito appAccessRiskVerdict ti aiuta a determinare se sono in esecuzione app che potrebbero essere utilizzate per acquisire la schermata, mostrare overlay o controllare il dispositivo (ad esempio, tramite l'uso improprio dell'autorizzazione di accessibilità).
• Malware noti: l'esito playProtectVerdict ti aiuta a stabilire se Google Play Protect è attivo e se ha trovato app rischiose o pericolose installate sul dispositivo.
• Iperattività: il livello recentDeviceActivity ti aiuta a determinare se un dispositivo ha effettuato un volume di richieste anomalo di recente, il che potrebbe indicare traffico automatizzato e potrebbe essere un segnale di attacco.
• Abuso ripetuto e riutilizzo dei dispositivi. deviceRecall (beta) ti aiuta a determinare se stai interagendo con un dispositivo che hai già segnalato, anche se la tua app è stata reinstallata o il dispositivo è stato ripristinato.

L'API può essere utilizzata su tutti i fattori di forma Android, inclusi smartphone, tablet, pieghevoli, Android Auto, Android TV, Android XR, ChromeOS, Wear OS e su Google Play Games per PC.

Considerazioni sulla sicurezza

L'API Play Integrity fornisce il massimo valore per la tua app se segui queste pratiche consigliate:

Adotta una strategia anti-abuso

L'API Play Integrity funziona in modo ottimale quando usata insieme ad altri indicatori in quanto parte della tua strategia generale contro i comportamenti illeciti e non come unico meccanismo anti-abuso. Utilizza questa API insieme ad altre best practice per la sicurezza appropriate per la tua app. Per impostazione predefinita, la tua app può effettuare fino a 10.000 richieste totali al giorno per tutte le installazioni. Puoi richiedere un aumento del numero massimo giornaliero.

Raccogli i dati di telemetria e comprendi il tuo pubblico prima di passare all'azione

Prima di modificare il comportamento della tua app in base agli esiti dell'API Play Integrity, puoi comprendere la situazione attuale con il tuo pubblico esistente implementando l'API senza applicazione forzata. Una volta che sai quali esiti restituiscono le tue installazioni attive, puoi stimare l'impatto di qualsiasi applicazione che stai pianificando e modificare la tua strategia anti-abuso di conseguenza.

Decidi come richiedere gli esiti relativi all'integrità

L'API Play Integrity offre due opzioni per richiedere e ricevere esiti relativi all'integrità. Che tu effettui richieste standard, richieste classiche o una combinazione di entrambi i tipi di richiesta, la risposta con l'esito di integrità verrà restituita nello stesso formato.

Le richieste API standard sono adatte a qualsiasi app o gioco e possono essere effettuate on demand per verificare che qualsiasi azione dell'utente o richiesta del server sia autentica. Le richieste standard hanno la latenza più bassa (in media poche centinaia di millisecondi) e un'elevata affidabilità nell'ottenere un esito utilizzabile. Le richieste standard utilizzano la memorizzazione nella cache on-device intelligente, delegando al contempo la protezione contro determinati tipi di attacchi a Google Play.

Anche le richieste API classiche, il metodo originale per richiedere esiti relativi all'integrità, continuano a essere disponibili. Le richieste Classic hanno una latenza più elevata (in media alcuni secondi) e sei responsabile della mitigazione del rischio di determinati tipi di attacchi. Le richieste classiche utilizzano più dati e batteria dell'utente rispetto alle richieste standard perché avviano una nuova valutazione, pertanto devono essere effettuate raramente come una tantum per verificare se un'azione altamente sensibile o di valore è autentica. Se stai pensando di effettuare una richiesta classica e memorizzarla nella cache per utilizzarla in un secondo momento, dovresti invece effettuare una richiesta standard per ridurre il rischio di attacchi.

La tabella seguente evidenzia alcune differenze chiave tra i due tipi di richieste:

	Richiesta API standard	Richiesta API classica
SDK Android minimo richiesto*	Android 6.0 (livello API 23) o versioni successive	Android 6.0 (livello API 23) o versioni successive
Warm up dell'API richiesto	✔️ (alcuni secondi)	❌
Latenza tipica delle richieste	Alcune centinaia di millisecondi	Pochi secondi
Frequenza delle richieste potenziali	Frequente (controllo on demand per qualsiasi azione o richiesta)	Infrequente (controllo una tantum per le azioni di maggior valore o le richieste più sensibili)
Mitigazione degli attacchi di tipo replay e simili	Mitigazione automatica da parte di Google Play	Utilizza il campo nonce con la logica lato server

* Per la libreria dell'API Play Integrity v1.4.0 e versioni successive, l'SDK Android minimo supportato è lo stesso per entrambi i tipi di richiesta ed è determinato dal valore minSdkVersion della libreria. Per le versioni 1.3.0 e precedenti, l'SDK Android minimo richiesto è Android 5.0 (livello API 21) per le richieste API standard e Android 4.4 (livello API 19) per le richieste API classiche.

Puoi visualizzare una tabella con altre differenze nelle considerazioni sulle richieste classiche.

Richiedi un esito di integrità in un momento appropriato

Per impedire ai truffatori di aggirare il controllo di integrità eseguito dalla tua app, devi richiedere un verdetto sul rischio di accesso all'app il più vicino possibile al momento dell'azione o della richiesta del server di cui vuoi impedire l'accesso.

Rendi le tue richieste API difficili da replicare

Le richieste API standard hanno un campo denominato requestHash che viene utilizzato per proteggere da manomissioni e attacchi simili. In questo campo, devi includere un digest di tutti i valori pertinenti della richiesta della tua app. Segui le indicazioni su come utilizzare l'associazione dei contenuti per proteggere le richieste standard della tua app.

Le richieste API Classic hanno un campo denominato nonce (abbreviazione di "number once"), che viene utilizzato per proteggere da determinati tipi di attacchi, come gli attacchi di replay e di manomissione. Segui le indicazioni su come generare nonce per proteggere le richieste classiche della tua app.

Attenzione: i dati che utilizzi per i campi requestHash e nonce sono visibili in chiaro alla tua app e a Google. Devi criptare o eseguire l'hashing dei dati prima di trasmetterli all'API Play Integrity.

Evita di memorizzare nella cache gli esiti di integrità

La memorizzazione nella cache degli esiti di integrità aumenta il rischio di proxying, un attacco in cui un malintenzionato riutilizza un esito di un dispositivo valido per scopi illeciti in un altro ambiente. Anziché memorizzare nella cache le risposte, puoi effettuare una richiesta API standard per ottenere un esito on demand.

Adotta una strategia di applicazione a più livelli

L'esito relativo all'integrità dell'API Play Integrity ha una gamma di possibili risposte che consentono di creare una strategia anti-abuso con più livelli di applicazioni forzate. Per farlo, configura il server di backend della tua app in modo che si comporti in modo diverso a seconda di ogni possibile risposta o gruppo di risposte.

Prima di valutare l'affidabilità del dispositivo, è essenziale controllare gli altri indicatori principali nella risposta dell'API:

• Dettagli della richiesta: assicurati che i requestDetails corrispondano ai valori previsti, in particolare verifica i requestHash o i nonce per evitare attacchi di tipo replay.
• Integrità dell'app: verifica che appRecognitionVerdict sia PLAY_RECOGNIZED, per confermare che il certificato di firma dell'app sia riconosciuto da Play e non sia stato manomesso.
• Dettagli account: verifica che appLicensingVerdict sia LICENSED, confermando che l'utente ha installato o aggiornato l'app da Google Play.

La tua app deve essere in grado di gestire i casi in cui questi controlli di base non vanno a buon fine, ad esempio utilizzando la finestra di dialogo di correzione di Play in-app. Inoltre, l'app deve essere in grado di gestire i codici di errore che potrebbero verificarsi durante la richiesta.

Una volta superati i controlli di base, è possibile suddividere in livelli la strategia di applicazione forzata in base all'affidabilità del dispositivo attivando la ricezione di etichette aggiuntive per i dispositivi nella risposta dell'API da Play Console. Ogni dispositivo restituirà tutte le etichette di cui soddisfa i criteri. Per ottenere la versione dell'SDK Android, devi utilizzare il campo deviceAttributes incluso nella risposta dell'API. La gamma di livelli di attendibilità dei dispositivi va dai dispositivi più attendibili a quelli meno attendibili:

• MEETS_STRONG_INTEGRITY (Android 13 e versioni successive): il livello di attendibilità del dispositivo più elevato, che richiede indicatori di sicurezza basati sull'hardware e una patch di sicurezza recente.
• MEETS_DEVICE_INTEGRITY (Android 13 e versioni successive) e MEETS_STRONG_INTEGRITY (precedente ad Android 13): il livello di attendibilità successivo. Entrambi si basano su indicatori di sicurezza supportati dall'hardware.
• MEETS_DEVICE_INTEGRITY (pre-Android 13): il livello successivo, che utilizza l'attestazione supportata dall'hardware, se disponibile, e l'attestazione supportata dal software come alternativa.
• MEETS_BASIC_INTEGRITY: il livello di attendibilità più debole, appena prima di non ricevere alcuna etichetta del dispositivo.

Ad esempio, dopo aver attivato la ricezione di tutte le etichette dei dispositivi, potresti scegliere di considerare più attendibile un dispositivo che restituisce MEETS_STRONG_INTEGRITY, MEETS_DEVICE_INTEGRITY e MEETS_BASIC_INTEGRITY rispetto a un dispositivo che restituisce solo MEETS_BASIC_INTEGRITY. Puoi rispondere in modo diverso dal server in ogni scenario.

Puoi quindi aggiungere altri indicatori alla tua strategia di applicazione a più livelli, ad esempio trattando i dispositivi come meno attendibili se restituiscono livelli più elevati in recentDeviceActivity.

Suggerimento: i dispositivi nei livelli di attendibilità più elevati sono meno rispetto a quelli nei livelli di attendibilità più bassi, pertanto è consigliabile adottare una strategia di applicazione a più livelli anziché fare affidamento esclusivamente sui livelli di attendibilità più elevati per massimizzare la copertura degli utenti.

Invia una serie di risposte dal tuo server alla tua app

Avere una gamma di risultati delle decisioni è più difficile da replicare rispetto all'invio di una risposta binaria "consenti" o "nega" dal server all'app per ogni risposta. Ad esempio, puoi utilizzare una serie di risposte correlate come Consenti, Consenti con limiti, Consenti con limiti dopo il completamento del CAPTCHA e Nega.

Rileva abusi ripetuti utilizzando il richiamo del dispositivo, preservando al contempo la privacy dell'utente

Il richiamo del dispositivo consente alle app di archiviare e recuperare alcuni dati personalizzati associati a un dispositivo specifico in modo da preservare la privacy dell'utente. I dati vengono archiviati sui server di Google, consentendo all'app di richiamare in modo affidabile i dati su ogni dispositivo anche dopo la reinstallazione dell'app o il ripristino del dispositivo. In questo modo, puoi reidentificare in modo affidabile un dispositivo che hai ritenuto abusivo in passato, in modo da poter passare all'azione e impedire che venga utilizzato di nuovo per abusi. Puoi definire il significato dei tre valori che compongono i dati di richiamo del dispositivo:

• Potresti utilizzarli come un massimo di tre flag o valori booleani separati. Ad esempio, i valori potrebbero indicare che un dispositivo ha o non ha creato un account, ha o non ha utilizzato una prova senza costi o è o non è noto per comportamenti illeciti di gravità elevata.
• In alternativa, puoi combinare tutti gli stati dei valori in un massimo di otto etichette personalizzate, ad esempio un'etichetta per lo stato predefinito quando tutti e tre i valori non sono modificati e sette etichette con significati personalizzati. In questo modo, puoi segmentare tutti i dispositivi in un massimo di otto gruppi in base ai comportamenti o alle azioni che definisci. In questo scenario, l'ultimo aggiornamento dei tre writeDates indica l'ultima volta che hai aggiornato l'etichetta.

Tieni presente anche i prerequisiti e altre considerazioni quando utilizzi i dati di richiamo del dispositivo.

Rileva abusi su larga scala utilizzando l'attività recente del dispositivo

Utilizza la funzionalità Attività del dispositivo recente nell'API Play Integrity per trovare i dispositivi che richiedono un numero elevato di token di integrità. Gli utenti che commettono attività illecite ad alto volume generano comunemente risultati di attestazione validi da dispositivi reali e li forniscono ai bot per automatizzare gli attacchi su dispositivi rooted ed emulatori. Puoi utilizzare il livello di attività del dispositivo recente per controllare quante attestazioni sono state generate dalla tua app su quel dispositivo nell'ultima ora.

Mostra messaggi di errore utili

Quando possibile, fornisci utili messaggi di errore all'utente per consentirgli di sapere cosa può fare per risolvere il problema, ad esempio riprovare, attivare la connessione a internet o verificare che l'app Play Store sia aggiornata.

Prepara un piano per problemi o interruzioni imprevisti

La dashboard dello stato di Play mostra informazioni sullo stato del servizio dell'API Play Integrity, nonché informazioni su eventuali interruzioni e problemi. Devi pianificare in anticipo il modo in cui vuoi che il server di backend funzioni nell'improbabile caso di un'interruzione su larga scala dell'API Play Integrity. Tieni presente che il tuo server di backend deve essere pronto a funzionare anche nel caso in cui le chiavi di attestazione di chiavi della piattaforma Android specifiche per i dispositivi vengano revocate.

Prendi in considerazione soluzioni antifrode aziendali end-to-end

I clienti aziendali che cercano una soluzione completa per la gestione di frodi e bot possono acquistare reCAPTCHA Enterprise per dispositivi mobili, che include SDK per Android che forniscono agli sviluppatori scoring del rischio di frode. reCAPTCHA Enterprise include automaticamente gli indicatori dell'API Play Integrity e li combina con gli indicatori di rete e applicazione di reCAPTCHA per i clienti, fornendo una soluzione di gestione delle frodi invisibile e senza problemi. Può anche fornire protezione per le app per Android in cui l'API Play Integrity non è disponibile.

Verifica il traffico rischioso quando accede a funzionalità sensibili o di alto valore

Identifica le azioni sensibili o di alto valore nella tua app o nel tuo gioco da proteggere con l'API Play Integrity anziché negare l'accesso direttamente. Quando possibile, verifica il traffico rischioso prima di consentire l'esecuzione di azioni di alto valore. Ad esempio, quando il rischio di accesso all'app indica che è in esecuzione un'app che potrebbe acquisire lo schermo, chiedi all'utente di disattivare o disinstallare le app che possono acquisire lo schermo prima di consentirgli di procedere alla funzionalità che vuoi proteggere.

Termini di servizio e sicurezza dei dati

Se accedi all'API Play Integrity o la utilizzi, accetti i Termini di servizio dell'API Play Integrity. Leggi e comprendi tutti i termini e le norme applicabili prima di accedere all'API.

Google Play ha una sezione Sicurezza dei dati in cui gli sviluppatori possono divulgare le prassi di raccolta, condivisione e sicurezza dei dati delle loro app per informare gli utenti. Per aiutarti a compilare il modulo dei dati, consulta queste informazioni su come l'API Play Integrity gestisce i dati.