Mit der Play Integrity API kannst du prüfen, ob Nutzeraktionen und Serveranfragen von deiner echten App stammen, die über Google Play installiert wurde und auf einem echten und zertifizierten Android-Gerät ausgeführt wird. Wenn riskante Interaktionen erkannt werden, z. B. von manipulierten App-Versionen, nicht vertrauenswürdigen Geräten oder emulierten Umgebungen, kann Ihr Backend-Server mit geeigneten Maßnahmen reagieren, um Missbrauch und unbefugten Zugriff zu verhindern, Betrug und Cheating zu bekämpfen und Nutzer vor Angriffen zu schützen.
Die API gibt Ergebnisse zurück, mit denen Sie potenzielle Bedrohungen erkennen können, darunter:
- Unautorisierter Zugriff: Mit dem Ergebnis
accountDetailskönnen Sie ermitteln, ob der Nutzer Ihre App oder Ihr Spiel bei Google Play installiert oder dafür bezahlt hat. - Codemanipulation: Mit dem Ergebnis
appIntegritykönnen Sie feststellen, ob Sie mit Ihrem unveränderten Binärprogramm in der Form interagieren, die Google Play bekannt ist. - Risikobehaftete Geräte und emulierte Umgebungen: Mit dem Ergebnis
deviceIntegritykönnen Sie feststellen, ob Ihre App auf einem echten, zertifizierten Android-Gerät oder einer echten Instanz von Google Play Games auf dem PC ausgeführt wird.
Google Play-Entwickler können auch zusätzliche Ergebnisse erhalten, um ein breiteres Spektrum potenzieller Bedrohungen zu erkennen, darunter:
- Geräte ohne Patch: Mit der Antwort
MEETS_STRONG_INTEGRITYimdeviceIntegrity-Ergebnis können Sie feststellen, ob auf einem Gerät (mit Android 13 und höher) aktuelle Sicherheitsupdates installiert wurden. - Risikoreicher Zugriff durch andere Apps: Mit dem
appAccessRiskVerdictkönnen Sie ermitteln, ob Apps ausgeführt werden, die möglicherweise den Bildschirm aufnehmen, Overlays einblenden oder das Gerät steuern können (z. B. durch Missbrauch der Bedienungshilfe-Berechtigung). - Bekannte Malware: Mit dem
playProtectVerdictkönnen Sie prüfen, ob Google Play Protect aktiviert ist und ob auf dem Gerät installierte Apps gefunden wurden, die als riskant oder gefährlich eingestuft werden. - Hyperaktivität: Mit der Ebene
recentDeviceActivitykönnen Sie feststellen, ob ein Gerät in letzter Zeit eine ungewöhnlich hohe Anzahl von Anfragen gesendet hat. Dies könnte auf automatisierten Traffic hindeuten und ein Zeichen für einen Angriff sein. - Wiederholter Missbrauch und wiederverwendete Geräte: Mit
deviceRecall(Beta) können Sie feststellen, ob Sie mit einem Gerät interagieren, das Sie zuvor gekennzeichnet haben, auch wenn Ihre App neu installiert oder das Gerät zurückgesetzt wurde.
Die API kann für alle Android-Formfaktoren verwendet werden, einschließlich Smartphones, Tablets, Foldables, Android Auto, Android TV, Android XR, ChromeOS, Wear OS und Google Play Games auf dem PC.
Sicherheitsaspekte
Die Play Integrity API bringt für Ihre App den größten Nutzen, wenn Sie die folgenden empfohlenen Vorgehensweisen befolgen:
Strategie zur Missbrauchsbekämpfung
Im Rahmen deiner Strategie gegen Missbrauch solltest du die Play Integrity API am besten zusammen mit anderen Signalen verwenden. Verwenden Sie diese API in Verbindung mit anderen geeigneten Best Practices für die Sicherheit Ihrer App. Standardmäßig kann Ihre App pro Tag bis zu 10.000 Anfragen über alle Installationen hinweg senden. Sie können eine Erhöhung des Tageslimits beantragen.
Telemetriedaten erfassen und Zielgruppe verstehen, bevor Sie Maßnahmen ergreifen
Bevor du das Verhalten deiner App basierend auf den Ergebnissen der Play Integrity API änderst, kannst du die API ohne Erzwingung implementieren, um die aktuelle Situation bei deiner bestehenden Zielgruppe zu verstehen. Sobald Sie wissen, welche Ergebnisse Ihre aktuelle Installationsbasis zurückgibt, können Sie die Auswirkungen aller geplanten Maßnahmen abschätzen und Ihre Strategie zur Missbrauchsbekämpfung entsprechend anpassen.
Entscheiden, wie Sie Integritätsergebnisse anfordern
Die Play Integrity API bietet zwei Optionen zum Anfordern und Erhalten von Integritätsergebnissen. Unabhängig davon, ob du Standardanfragen, klassische Anfragen oder eine Kombination aus beiden Arten von Anfragen sendest, wird die Antwort mit dem Integritätsergebnis im selben Format zurückgegeben.
Standard-API-Anfragen eignen sich für alle Apps und Spiele und können bei Bedarf gestellt werden, um zu prüfen, ob eine Nutzeraktion oder Serveranfrage echt ist. Standardanfragen haben die niedrigste Latenz (durchschnittlich einige Hundert Millisekunden) und eine hohe Zuverlässigkeit, um ein brauchbares Urteil zu erhalten. Bei Standardanfragen wird ein intelligentes On-Device-Caching verwendet, während der Schutz vor bestimmten Arten von Angriffen an Google Play delegiert wird.
Klassische API-Anfragen, die ursprüngliche Methode zum Anfordern von Integritätsergebnissen, sind ebenfalls weiterhin verfügbar. Klassische Anfragen haben eine höhere Latenz (durchschnittlich einige Sekunden) und Sie sind dafür verantwortlich, das Risiko bestimmter Arten von Angriffen zu minimieren. Klassische Anfragen verbrauchen mehr Daten und Akku als Standardanfragen, da sie eine neue Bewertung initiieren. Sie sollten daher nur selten und einmalig verwendet werden, um zu prüfen, ob eine hochsensible oder wertvolle Aktion echt ist. Wenn Sie eine klassische Anfrage stellen und diese für die spätere Verwendung im Cache speichern möchten, sollten Sie stattdessen eine Standardanfrage stellen, um das Risiko von Angriffen zu verringern.
In der folgenden Tabelle sind einige wichtige Unterschiede zwischen den beiden Arten von Anfragen aufgeführt:
| Standard-API-Anfrage | Klassische API-Anfrage | |
|---|---|---|
| Erforderliches Android SDK (Mindestversion)* | Android 6.0 (API-Level 23) oder höher | Android 6.0 (API-Level 23) oder höher |
| API-Warm-up erforderlich | ✔️ (ein paar Sekunden) | ❌ |
| Typische Anfragelatenz | Einige hundert Millisekunden | Ein paar Sekunden |
| Mögliche Anfragehäufigkeit | Häufig (On-Demand-Prüfung für jede Aktion oder Anfrage) | Selten (einmalige Überprüfung bei Aktionen mit dem höchsten Wert oder bei besonders sensiblen Anfragen) |
| Schutz vor Replay- und ähnlichen Angriffen | Automatische Aussetzung von Maßnahmen durch Google Play | Feld nonce mit serverseitiger Logik verwenden |
* Für die Play Integrity API-Bibliothek v1.4.0 und höher ist das mindestens unterstützte Android SDK für beide Anfragetypen gleich und wird durch die minSdkVersion der Bibliothek bestimmt. Für v1.3.0 und frühere Versionen ist das mindestens erforderliche Android SDK Android 5.0 (API-Level 21) für Standard-API-Anfragen und Android 4.4 (API-Level 19) für Classic API-Anfragen.
Eine Tabelle mit weiteren Unterschieden finden Sie unter Überlegungen zu klassischen Anfragen.
Integritätsurteil zu einem geeigneten Zeitpunkt anfordern
Sie sollten ein Urteil zum Risiko von App-Zugriffen so nah wie möglich am Zeitpunkt der Aktion oder Serveranfrage anfordern, die Sie vor Zugriffen schützen möchten. So verhindern Sie, dass Betrüger die von Ihrer App durchgeführte Integritätsprüfung umgehen.
API-Anfragen schwer replizierbar machen
Standard-API-Anfragen haben ein Feld namens requestHash, das zum Schutz vor Manipulationen und ähnlichen Angriffen verwendet wird. In diesem Feld sollten Sie einen Digest aller relevanten Werte aus der Anfrage Ihrer App angeben. Folgen Sie der Anleitung zur Verwendung der Inhaltsbindung, um die Standardanfragen Ihrer App zu schützen.
Klassische API-Anfragen haben ein Feld namens nonce (kurz für „number once“), das zum Schutz vor bestimmten Arten von Angriffen wie Replay- und Manipulationsangriffen verwendet wird. Folgen Sie der Anleitung zum Generieren von Nonces, um die klassischen Anfragen Ihrer App zu schützen.
Integritätsergebnisse nicht im Cache speichern
Das Caching von Integritätsergebnissen erhöht das Risiko von Proxying. Dabei handelt es sich um einen Angriff, bei dem ein böswilliger Akteur ein Ergebnis von einem guten Gerät für missbräuchliche Zwecke in einer anderen Umgebung wiederverwendet. Anstatt Antworten im Cache zu speichern, können Sie eine Standard-API-Anfrage stellen, um ein Ergebnis bei Bedarf zu erhalten.
Mehrstufige Durchsetzungsstrategie
Das Integritätsergebnis der Play Integrity API kann verschiedene Antworten liefern, die eine mehrstufige Strategie ermöglichen. Dazu können Sie den Backend-Server Ihrer App so konfigurieren, dass er sich je nach möglicher Antwort oder Antwortgruppe anders verhält.
Bevor Sie die Vertrauenswürdigkeit des Geräts bewerten, sollten Sie die anderen Kernsignale in der API-Antwort prüfen:
- Anfragedetails: Prüfen Sie, ob die
requestDetailsmit den erwarteten Werten übereinstimmen. Prüfen Sie insbesondere dierequestHashodernonce, um Replay-Angriffe zu verhindern. - App-Integrität: Prüfen Sie, ob
appRecognitionVerdictden WertPLAY_RECOGNIZEDhat. Das bedeutet, dass das Signaturzertifikat der App von Google Play erkannt wurde und nicht manipuliert wurde. - Kontodetails: Prüfen Sie, ob
appLicensingVerdictden WertLICENSEDhat. Das bestätigt, dass der Nutzer die App über Google Play installiert oder aktualisiert hat.
Ihre App sollte in der Lage sein, mit dem Fehlschlagen dieser grundlegenden Prüfungen umzugehen, z. B. mithilfe des In-App-Dialogfelds zur Fehlerbehebung bei Google Play. Außerdem sollte Ihre App in der Lage sein, Fehlercodes zu verarbeiten, die während der Anfrage auftreten können.
Sobald die grundlegenden Prüfungen bestanden sind, können Sie Ihre Erzwingungsstrategie basierend auf der Vertrauenswürdigkeit des Geräts abstufen, indem Sie in der API-Antwort der Play Console zusätzliche Gerätelabels aktivieren. Jedes Gerät gibt alle Labels zurück, deren Kriterien es erfüllt. Die Android SDK-Version finden Sie im Feld deviceAttributes in der API-Antwort.
Die Bandbreite der Device-Trust-Stufen reicht von vertrauenswürdigeren bis zu weniger vertrauenswürdigen Geräten:
MEETS_STRONG_INTEGRITY(Android 13 und höher): Die höchste Vertrauensstufe für Geräte, die hardwaregestützte Sicherheitssignale und einen aktuellen Sicherheitspatch erfordert.MEETS_DEVICE_INTEGRITY(Android 13 oder höher) undMEETS_STRONG_INTEGRITY(vor Android 13): Die nächste Vertrauensstufe. Beide basieren auf hardwaregestützten Sicherheitssignalen.MEETS_DEVICE_INTEGRITY(vor Android 13): Die nächste Stufe, bei der hardwaregestützte Attestierung verwendet wird, sofern verfügbar, und softwaregestützte Attestierung als Fallback.MEETS_BASIC_INTEGRITY: Die schwächste Vertrauensstufe, kurz bevor überhaupt keine Gerätelabels mehr empfangen werden.
Wenn Sie sich beispielsweise für den Erhalt aller Gerätelabels entschieden haben, können Sie einem Gerät, das MEETS_STRONG_INTEGRITY, MEETS_DEVICE_INTEGRITY und MEETS_BASIC_INTEGRITY zurückgibt, mehr vertrauen als einem Gerät, das nur MEETS_BASIC_INTEGRITY zurückgibt. Sie können in jedem Szenario anders als der Server reagieren.
Sie können dann weitere Signale in Ihre gestaffelte Erzwingungsstrategie einbeziehen, z. B. Geräte als weniger vertrauenswürdig behandeln, die höhere Werte in recentDeviceActivity zurückgeben.
Eine Reihe von Antworten von Ihrem Server an Ihre App senden
Eine Reihe von Entscheidungsergebnissen ist schwieriger zu replizieren, als für jede Antwort eine binäre „Zulassen“- oder „Ablehnen“-Antwort vom Server an die App zu senden. Sie können beispielsweise eine Reihe von zugehörigen Antworten wie „Zulassen“, „Mit Einschränkungen zulassen“, „Mit Einschränkungen nach CAPTCHA-Abschluss zulassen“ und „Ablehnen“ verwenden.
Wiederholte Fälle von Missbrauch mithilfe der Gerätewiedererkennung erkennen und gleichzeitig den Datenschutz für Nutzer schützen
Mit der Gerätewiedererkennung können Apps benutzerdefinierte Daten, die mit einem bestimmten Gerät verknüpft sind, so speichern und wiedererkennen, dass die Privatsphäre der Nutzer geschützt bleibt. Die Daten werden auf Google-Servern gespeichert, sodass deine App zuverlässig Daten für jedes Gerät abrufen kann, auch wenn die App neu installiert oder das Gerät zurückgesetzt wurde. So kannst du ein Gerät, das in der Vergangenheit für Missbrauch verwendet wurde, zuverlässig wiedererkennen, Maßnahmen ergreifen und verhindern, dass es noch einmal für Missbrauch verwendet wird. Sie können die drei Werte, aus denen sich die Daten zur Gerätewiedererkennung zusammensetzen, selbst definieren:
- Sie können sie als bis zu drei separate Flags oder boolesche Werte verwenden. Die Werte können beispielsweise angeben, ob auf einem Gerät ein Konto erstellt wurde, ob ein kostenloser Testzeitraum eingelöst wurde oder ob das Gerät für schwerwiegenden Missbrauch bekannt ist.
- Alternativ können Sie alle Zustände der Werte in bis zu acht benutzerdefinierten Labels kombinieren, z. B. ein Label für den Standardzustand, wenn alle drei Werte unverändert sind, und sieben Labels mit benutzerdefinierten Bedeutungen. So können Sie alle Geräte anhand von Verhaltensweisen oder Aktionen, die Sie definieren, in bis zu acht Gruppen segmentieren. In diesem Szenario gibt der zuletzt aktualisierte der drei
writeDates-Werte an, wann Sie das Label zuletzt aktualisiert haben.
Beachten Sie auch die Voraussetzungen und andere Überlegungen bei der Arbeit mit Gerätewiedererkennungsdaten.
Missbrauch in großem Umfang anhand der letzten Geräteaktivitäten erkennen
Mit der Funktion Letzte Geräteaktivitäten in der Play Integrity API können Sie Geräte finden, die eine große Anzahl von Integritäts-Tokens anfordern. Missbraucher mit hohem Aktivitätsvolumen generieren häufig gültige Attestierungsergebnisse von echten Geräten und stellen sie Bots zur Verfügung, um Angriffe auf gerootete Geräte und Emulatoren zu automatisieren. Anhand der letzten Geräteaktivitäten können Sie sehen, wie viele Attestierungen Ihre App in der letzten Stunde auf diesem Gerät generiert hat.
Fehlermeldungen mit Handlungsaufforderung anzeigen
Falls möglich, solltest du Nutzern informative Fehlermeldungen zur Problembehebung bereitstellen, z. B. dass sie es noch einmal versuchen, ihre Internetverbindung aktivieren oder prüfen sollen, ob die Google Play Store App auf dem neuesten Stand ist.
Plan für unerwartete Probleme oder Ausfälle erstellen
Das Google Play-Status-Dashboard enthält Informationen zum Dienststatus der Play Integrity API sowie zu Störungen und Ausfällen. Sie sollten im Voraus planen, wie sich Ihr Backend-Server im unwahrscheinlichen Fall eines großflächigen Ausfalls der Play Integrity API verhalten soll. Ihr Backend-Server sollte auch dann funktionieren, wenn gerätespezifische Schlüssel für die Schlüsselattestierung der Android-Plattform widerrufen werden.
End-to-End-Lösungen zur Betrugsbekämpfung für Unternehmen
Unternehmenskunden, die eine Komplettlösung für die Betrugs- und Bot-Verwaltung suchen, können reCAPTCHA Enterprise für Mobilgeräte erwerben. Es enthält SDKs für Android, die Entwicklern Betrugsrisikobewertungen liefern. reCAPTCHA Enterprise enthält automatisch Play Integrity API-Signale und kombiniert sie für Kunden mit reCAPTCHA-Netzwerk- und Anwendungssignalen. So erhalten sie eine reibungslose, unsichtbare Lösung für die Betrugsverwaltung. Sie kann auch Schutz für Android-Apps bieten, für die die Play Integrity API nicht verfügbar ist.
Risikoreichen Traffic beim Zugriff auf hochwertige oder vertrauliche Funktionen prüfen
Identifizieren Sie wichtige oder vertrauliche Aktionen in Ihrer App oder Ihrem Spiel, die Sie mit der Play Integrity API schützen möchten, anstatt den Zugriff direkt zu verweigern. Wenn möglich, sollten Sie riskanten Traffic prüfen, bevor Sie hochwertige Aktionen zulassen. Wenn das Risiko von App-Zugriffen beispielsweise darauf hindeutet, dass eine App ausgeführt wird, die den Bildschirm aufnehmen könnte, bitten Sie den Nutzer, Apps zu deaktivieren oder zu deinstallieren, die den Bildschirm aufnehmen können, bevor Sie ihm Zugriff auf Funktionen gewähren, die Sie schützen möchten.
Nutzungsbedingungen und Datensicherheit
Wenn Sie auf die Play Integrity API zugreifen oder sie verwenden, stimmen Sie den Nutzungsbedingungen der Play Integrity API zu. Lesen und verstehen Sie alle anwendbaren Bedingungen und Richtlinien, bevor Sie auf die API zugreifen.
Google Play bietet einen Abschnitt zur Datensicherheit, in dem Entwickler die Praktiken ihrer Apps hinsichtlich Datenerhebung, -weitergabe und -sicherheit offenlegen können, um Nutzer zu informieren. Informationen zum Ausfüllen des Datenformulars finden Sie unter So verarbeitet die Play Integrity API Daten.