Übersicht über die Play Integrity API

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. Durch die Erkennung riskanter Interaktionen, z. B. von manipulierten App-Versionen, nicht vertrauenswürdigen Geräten oder emulierten Umgebungen, kann dein Backend-Server mit geeigneten Aktionen reagieren, um Missbrauch und unbefugten Zugriff zu verhindern, Betrug zu bekämpfen, Täuschung zu verhindern und Nutzer vor Angriffen zu schützen.

Die API gibt Ergebnisse zurück, mit denen du potenzielle Bedrohungen erkennen kannst, darunter:

• Unbefugter Zugriff: Mit dem Ergebnis accountDetails kannst du ermitteln, ob der Nutzer deine App oder dein Spiel bei Google Play installiert oder gekauft hat.
• Manipulation von Code: Mit dem appIntegrity Ergebnis kannst du ermitteln ob du mit deinem unveränderten Binärprogramm in der Form interagierst, die Google Play bekannt ist.
• Risikoreiche Geräte und emulierte Umgebungen: Mit dem deviceIntegrity Ergebnis kannst du ermitteln, ob deine App auf einem echten zertifizierten Android-Gerät oder einer echten Instanz von Google Play Games für 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 aktuelle Sicherheitspatches: Mit der MEETS_STRONG_INTEGRITY Antwort im deviceIntegrity Ergebnis kannst du ermitteln, ob auf einem Gerät die neuesten Sicherheitsupdates installiert wurden (für Geräte mit Android 13 und höher).
• Risikoreicher Zugriff durch andere Apps:Mit dem Ergebnis appAccessRiskVerdict kannst du 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 Berechtigung für Bedienungshilfen).
• Bekannte Malware:Mit dem Ergebnis playProtectVerdict kannst du ermitteln, 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 dem Wert recentDeviceActivity kannst du ermitteln, ob ein Gerät in letzter Zeit eine ungewöhnlich hohe Anzahl von Anfragen gesendet hat. Dies könnte auf automatisierten Traffic und einen Angriff hindeuten.
• Wiederholter Missbrauch und wiederverwendete Geräte:Mit deviceRecall (Beta) kannst du ermitteln, ob du mit einem Gerät interagierst, das du zuvor gekennzeichnet hast – auch wenn deine App neu installiert oder das Gerät zurückgesetzt wurde.

Die API kann für alle Android-Formfaktoren verwendet werden, einschließlich Smartphones, Tablets, faltbare Geräte, Android Auto, Android TV, Android XR, ChromeOS, Wear OS und Google Play Games für PC.

Sicherheitsaspekte

Die Play Integrity API bringt für deine App den größten Nutzen, wenn du diese Best Practices befolgst:

Strategie gegen Missbrauch

Im Rahmen deiner Strategie gegen Missbrauch solltest du die Play Integrity API am besten zusammen mit anderen Signalen verwenden. Verwende diese API in Kombination mit anderen geeigneten Best Practices für die Sicherheit deiner App. Standardmäßig kann deine App pro Tag insgesamt bis zu 10.000 Anfragen für alle Installationen senden. Du kannst eine Erhöhung des täglichen Maximumsbeantragen.

Telemetriedaten erheben und Zielgruppe kennenlernen, bevor Maßnahmen ergriffen werden

Bevor du das Verhalten deiner App basierend auf den Ergebnissen der Play Integrity API änderst, kannst du die aktuelle Situation mit deiner bestehenden Zielgruppe analysieren, indem du die API ohne Erzwingung implementierst. Sobald du weißt, welche Ergebnisse deine aktuelle Installationsbasis zurückgibt, kannst du die Auswirkungen der geplanten Erzwingung abschätzen und deine Strategie gegen Missbrauch entsprechend anpassen.

Festlegen, wie Integritätsergebnisse angefordert werden

Die Play Integrity API bietet zwei Optionen zum Anfordern und Empfangen von Integritätsergebnissen. Unabhängig davon, ob du Standardanfragen, klassische Anfragen oder eine Kombination aus beiden Anfragetypen sendest, wird die Antwort mit dem Integritätsergebnis im selben Format zurückgegeben.

Standard-API-Anfragen eignen sich für jede App oder jedes Spiel und können bei Bedarf gesendet 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 bei der Erzielung eines nutzbaren Ergebnisses. Bei Standardanfragen wird intelligentes Caching auf dem Gerät 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 du bist für die Eindämmung des Risikos bestimmter Arten von Angriffen verantwortlich. Bei klassischen Anfragen werden mehr Daten und mehr Akkuleistung des Nutzers verbraucht als bei Standardanfragen, da eine neue Bewertung initiiert wird. Sie sollten daher nur selten als einmalige Prüfung verwendet werden, um zu prüfen, ob eine sehr sensible oder wertvolle Aktion echt ist. Wenn du eine klassische Anfrage senden und das Ergebnis für die spätere Verwendung im Cache speichern möchtest, solltest du stattdessen eine Standardanfrage senden, um das Risiko von Angriffen zu verringern.

In der folgenden Tabelle sind einige wichtige Unterschiede zwischen den beiden Anfragetypen aufgeführt:

	Standard-API-Anfrage	Klassische API-Anfrage
Erforderliches Android SDK (Minimum)*	Android 6.0 (API-Level 23) oder höher	Android 6.0 (API-Level 23) oder höher
API-Aufwärmen erforderlich	✔️ (einige Sekunden)	❌
Typische Latenz der Anfrage	Einige Hundert Millisekunden	Einige Sekunden
Mögliche Häufigkeit der Anfragen	Häufig (On-Demand-Prüfung für jede Aktion oder Anfrage)	Selten (einmalige Prüfung für Aktionen mit dem höchsten Wert oder die sensibelsten Anfragen)
Schutz vor Replay-Angriffen und ähnlichen Angriffen	Automatische Eindämmung durch Google Play	Feld nonce mit serverseitiger Logik verwenden

* Für die Play Integrity API-Bibliothek v1.4.0 und höher ist das unterstützte Android SDK (Minimum) für beide Anfragetypen gleich und wird durch minSdkVersion der Bibliothek bestimmt. Für Version 1.3.0 und früher ist das erforderliche Android SDK (Minimum) Android 5.0 (API-Level 21) für Standard-API-Anfragen und Android 4.4 (API-Level 19) für klassische API-Anfragen.

In einer Tabelle mit weiteren Unterschieden findest du weitere Informationen zu klassischen Anfragen.

Integritätsergebnis zum richtigen Zeitpunkt anfordern

Du solltest ein Ergebnis zum Risiko von App-Zugriffen so nah wie möglich am Zeitpunkt der Aktion oder Serveranfrage anfordern, vor der du dich schützen möchtest. So verhinderst du, dass Betrüger die von deiner App durchgeführte Integritätsprüfung umgehen.

API-Anfragen schwer zu replizieren machen

Standard-API-Anfragen haben ein Feld namens requestHash, das zum Schutz vor Manipulationen und ähnlichen Angriffen verwendet wird. In diesem Feld solltest du einen Digest aller relevanten Werte aus der Anfrage deiner App angeben. Folge der Anleitung zur Verwendung der Inhaltsbindung, um die Standardanfragen deiner App zu schützen.

Klassische API-Anfragen haben ein Feld namens nonce (Abkürzung für „number once“), das zum Schutz vor bestimmten Arten von Angriffen verwendet wird, z. B. Replay- und Manipulationsangriffen. Folge der Anleitung zum Generieren von Nonces, um die klassischen Anfragen deiner App zu schützen.

Integritätsergebnisse nicht im Cache speichern

Das Caching von Integritätsergebnissen erhöht das Risiko von Proxying. Bei dieser Art von Angriff verwendet ein böswilliger Akteur ein Ergebnis von einem guten Gerät für missbräuchliche Zwecke in einer anderen Umgebung. Anstatt Antworten im Cache zu speichern, kannst du eine Standard-API Anfrage senden, um bei Bedarf ein Ergebnis zu erhalten.

Mehrstufige Erzwingungsstrategie

Das Integritätsergebnis der Play Integrity API kann verschiedene Antworten liefern, die eine mehrstufige Strategie ermöglichen. Dazu kannst du den Backend-Server deiner App so konfigurieren, dass er sich je nach Antwort oder Gruppe von Antworten anders verhält.

Bevor du die Vertrauenswürdigkeit eines Geräts bewertest, musst du die anderen Kernsignale in der API-Antwort prüfen:

• Anfragedetails:Prüfe, ob die requestDetails mit den erwarteten Werten übereinstimmen. Überprüfe insbesondere requestHash oder nonce, um Replay-Angriffe zu verhindern.
• App-Integrität:Prüfe, ob appRecognitionVerdict den Wert PLAY_RECOGNIZED hat. Dies bestätigt, dass das Signaturzertifikat der App von Play erkannt und nicht manipuliert wurde.
• Kontodetails:Prüfe, ob appLicensingVerdict den Wert LICENSED hat. Dies bestätigt, dass der Nutzer die App über Google Play installiert oder aktualisiert hat.

Deine App sollte in der Lage sein, Fehler bei diesen grundlegenden Prüfungen zu verarbeiten, z. B. mit dem In-App-Dialog zur Problembehebung von Play. Außerdem sollte deine App auch in der Lage sein, Fehlercodes zu verarbeiten, die während der Anfrage auftreten können.

Sobald die grundlegenden Prüfungen bestanden wurden, kannst du deine Erzwingungsstrategie basierend auf der Vertrauenswürdigkeit des Geräts abstufen. Dazu kannst du in der Play Console zusätzliche Gerätelabels in deiner API-Antwort aktivieren. Für jedes Gerät werden alle Labels zurückgegeben, deren Kriterien es erfüllt. Um die Android SDK-Version zu erhalten, solltest du das Feld deviceAttributes verwenden, das in der API-Antwort enthalten ist. Die Abstufungen der Gerätevertrauenswürdigkeit reichen von vertrauenswürdigeren bis hin zu weniger vertrauenswürdigen Geräten:

• MEETS_STRONG_INTEGRITY (Android 13 und höher): Die höchste Stufe der Gerätevertrauenswürdigkeit, die hardwaregestützte Sicherheitssignale und einen aktuellen Sicherheitspatch erfordert.
• MEETS_DEVICE_INTEGRITY (Android 13 und höher) und MEETS_STRONG_INTEGRITY (vor Android 13): Die nächste Stufe der Vertrauenswürdigkeit. Beide basieren auf hardwaregestützten Sicherheitssignalen.
• MEETS_DEVICE_INTEGRITY (vor Android 13): Die nächste Stufe, bei der hardwaregestützte Attestierung verwendet wird, wenn sie verfügbar ist, und softwaregestützte Attestierung als Fallback.
• MEETS_BASIC_INTEGRITY: Die niedrigste Stufe der Vertrauenswürdigkeit, kurz bevor überhaupt keine Gerätelabels empfangen werden.

Wenn du beispielsweise alle Gerätelabels aktiviert hast, kannst du ein Gerät, das MEETS_STRONG_INTEGRITY, MEETS_DEVICE_INTEGRITY und MEETS_BASIC_INTEGRITY zurückgibt, als vertrauenswürdiger einstufen als ein Gerät, das nur MEETS_BASIC_INTEGRITY zurückgibt. Du kannst in jedem Szenario anders vom Server aus reagieren.

Anschließend kannst du andere Signale in deine mehrstufige Erzwingungsstrategie einbeziehen, z. B. Geräte als weniger vertrauenswürdig behandeln, die höhere Werte in recentDeviceActivity zurückgeben.

Verschiedene Antworten vom Server an die App senden

Eine Reihe von Entscheidungen ist schwieriger zu replizieren als eine binäre Antwort (Zulassen/Ablehnen), die für jede Antwort vom Server an die App gesendet wird. Du könntest beispielsweise eine Reihe verwandter Antworten verwenden, z. B. „Zulassen“, „Mit Einschränkungen zulassen“, „Mit Einschränkungen zulassen nach Abschluss des CAPTCHA“ und „Ablehnen“.

Wiederholten Missbrauch mit der Gerätewiedererkennung erkennen und gleichzeitig die Privatsphäre der Nutzer schützen

Mit der Gerätewiedererkennung können Apps benutzerdefinierte Daten, die mit einem bestimmten Gerät verknüpft sind, auf eine Weise speichern und abrufen, die Nutzerdaten schützt. 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 missbräuchlich verwendet wurde, zuverlässig wiedererkennen, um Maßnahmen zu ergreifen und zu verhindern, dass es erneut für Missbrauch verwendet wird. Du kannst die Bedeutung der drei Werte definieren, aus denen die Daten zur Gerätewiedererkennung bestehen:

• Du kannst sie als bis zu drei separate Flags oder boolesche Werte verwenden. Die Werte könnten beispielsweise angeben, ob ein Gerät ein Konto erstellt hat oder nicht, ob eine kostenlose Testversion eingelöst wurde oder nicht oder ob es für schwerwiegenden Missbrauch bekannt ist oder nicht.
• Alternativ kannst du 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 kannst du alle Geräte in bis zu acht Gruppen segmentieren, basierend auf von dir definierten Verhaltensweisen oder Aktionen. In diesem Szenario gibt das zuletzt aktualisierte der drei writeDates an, wann du das Label zuletzt aktualisiert hast.

Beachte auch die Voraussetzungen und andere Aspekte bei der Arbeit mit Daten zur Gerätewiedererkennung.

Umfassenden Missbrauch mit der Funktion „Letzte Geräteaktivitäten“ erkennen

Mit der Funktion „Letzte Geräteaktivitäten“ in der Play Integrity API kannst du Geräte finden, die eine große Anzahl von Integritäts-Tokens anfordern. Missbraucher, die in großem Umfang aktiv sind, 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. Mit der Funktion „Letzte Geräteaktivitäten“ kannst du prüfen, wie viele Attestierungen in der letzten Stunde von deiner App auf diesem Gerät generiert wurden.

Umsetzbare Fehlermeldungen anzeigen

Falls möglich, solltest du Nutzern informative Fehlermeldungen zur Problembehebung bereitstellen. Sie könnten beispielsweise aufgefordert werden, es noch einmal zu versuchen, die Internetverbindung zu aktivieren oder zu prüfen, ob die Google Play Store App auf dem neuesten Stand ist.

Plan für unerwartete Probleme oder Ausfälle

Im Google Play-Status-Dashboard findest du Informationen zum Dienststatus der Play Integrity API sowie Informationen zu Unterbrechungen und Ausfällen. Du solltest im Voraus planen, wie sich dein Backend-Server im unwahrscheinlichen Fall eines großflächigen Ausfalls der Play Integrity API verhalten soll. Beachte, dass dein Backend-Server auch dann funktionieren muss, wenn gerätespezifische Android Platform Schlüsselattestierungsschlüssel widerrufenwerden.

End-to-End-Lösungen für Betrugsbekämpfung für Unternehmen in Betracht ziehen

Unternehmen, die eine umfassende Lösung für Betrugs- und Bot-Management suchen, können reCAPTCHA Enterprise für Mobilgeräte erwerben. Dieses Produkt enthält SDKs für Android, die Entwicklern Risikobewertungen für Betrug liefern. reCAPTCHA Enterprise umfasst automatisch Signale der Play Integrity API und kombiniert sie mit reCAPTCHA-Netzwerk- und Anwendungssignalen für Kunden. So wird eine reibungslose, unsichtbare Lösung für das Betrugs- management bereitgestellt. Es kann auch Schutz für Android-Apps bieten, bei denen die Play Integrity API nicht verfügbar ist.

Risikoreichen Traffic bei Zugriff auf hochwertige oder sensible Funktionen durch Sicherheitsmaßnahmen einschränken

Identifiziere hochwertige oder sensible Aktionen in deiner App oder deinem Spiel, die mit der Play Integrity API geschützt werden sollen, anstatt den Zugriff direkt zu verweigern. Falls möglich, solltest du risikoreichen Traffic durch Sicherheitsmaßnahmen einschränken, bevor du Aktionen mit hohem Wert zulässt. Wenn das Risiko von App-Zugriffen beispielsweise darauf hindeutet, dass eine App ausgeführt wird, die den Bildschirm aufnehmen kann, fordere den Nutzer auf, Apps zu deaktivieren oder zu deinstallieren, die den Bildschirm aufnehmen können, bevor er Funktionen verwenden darf, die du schützen möchtest.

Nutzungsbedingungen und Datensicherheit

Wenn du auf die Play Integrity API zugreifst oder sie verwendest, stimmst du den Nutzungsbedingungen der Play Integrity API zu. Lies dir alle geltenden Nutzungsbedingungen und Richtlinien durch, bevor du auf die API zugreifst.

Google Play bietet einen Abschnitt zur Datensicherheit, in dem Entwickler ihre Praktiken hinsichtlich Datenerhebung, -weitergabe und -sicherheit offenlegen können, um Nutzer zu informieren. Weitere Informationen zum Ausfüllen des Datenformulars findest du hier.