App Integrity & Injection Flashcards
SECURITY › Security
- What three things does the Play Integrity API let you assess?
- App integrity (genuine unmodified binary from Play), device integrity (genuine Android device), and account/licensing details (whether the user has a legitimate Play license).
- Why must Play Integrity tokens be verified on your backend rather than in the app?
- The token is encrypted and decrypted/verified server-side via Google Play. A rooted or tampered client could fake or bypass any in-app check, so on-device verification provides no real trust; only a server you control can enforce the verdict.
- What do MEETS_BASIC_INTEGRITY, MEETS_DEVICE_INTEGRITY and MEETS_STRONG_INTEGRITY mean?
- BASIC: passes basic checks (may be rooted/emulator/custom ROM). DEVICE: genuine Play-Protect-certified Android device. STRONG: device integrity plus hardware-backed proof and recent security updates. MEETS_VIRTUAL_INTEGRITY indicates a Play-backed emulator.
- What is the difference between standard and classic Play Integrity requests?
- Standard requests are the recommended default: low latency, use a request hash, and rely on Play caching for frequent checks. Classic requests are higher latency/cost, use a one-time nonce, and suit infrequent high-value actions; you generate a fresh nonce to prevent replay.
- Can root/tamper detection guarantee your app is safe on a device?
- No. A sufficiently capable attacker controls the device, so any on-device check (root, hooking frameworks, debugger) can be patched out or spoofed. Detection only raises attacker cost and is best combined with server-side integrity signals and not relied on alone.
- Is code obfuscation a security control? What does R8 actually give you?
- Obfuscation is defence-in-depth, not security on its own. R8 shrinks and renames symbols, making reverse engineering harder and slower, but it does not encrypt logic or protect secrets. It raises cost; it never makes a determined attacker impossible.
- How do you prevent SQL injection with the raw SQLite APIs?
- Never concatenate user input into SQL. Use ? placeholders with selectionArgs in SQLiteDatabase.query(), or rawQuery("... WHERE col = ?", arrayOf(value)). The arguments are bound and escaped separately, so input is treated as data, not executable SQL.
- How does Room protect against SQL injection?
- Room binds named @Query parameters (e.g. :email) as bound arguments rather than string concatenation, and it verifies the SQL at compile time. You still must avoid building dynamic SQL with @RawQuery using concatenated strings.
- What are the key WebView hardening steps when loading web content?
- Disable JavaScript unless required, avoid setAllowFileAccess/file:// access to app data, only call addJavascriptInterface for trusted content (it exposes native methods), validate/allowlist loaded URLs, and prefer HTTPS. Treat any web content as untrusted input.