App Integrity & Injection Interview Questions
SECURITY › Security
Walk me through how you'd design the backend flow for verifying a Play Integrity token end to end. What has to happen server-side, and what's the wrong way teams often build this?
What a strong answer covers: A strong answer describes the client requesting a token bound to a nonce or request hash tied to the specific action being protected, sending the opaque token to the backend, and the backend calling Google's verification endpoint to get the decrypted verdict, then checking appRecognitionVerdict, deviceIntegrity, and account details before trusting the request; the token must never be decrypted or trusted client-side since a compromised client could fabricate a positive verdict. Should call out the common mistake: checking the verdict on-device, or failing to bind the nonce to the specific request, which makes the token replayable across different actions.
When would you actually invest in root or tamper detection for an app, given it's not a real security guarantee? What's a legitimate reason to add it, and what's the trap of over-relying on it?
What a strong answer covers: A legitimate reason is raising attacker cost and feeding a broader risk signal for business needs like anti-cheat, content protection, or fraud scoring, not as a hard security boundary, since any client-side check can eventually be patched out or hooked by a motivated attacker using tools like Frida or a custom ROM. The trap is treating a positive tamper-detection result as proof of safety and skipping server-side authorization, when the right architecture is defense-in-depth: root and tamper signals as one input among several, with security-critical decisions enforced server-side regardless.
A teammate wants to add a WebView feature that loads a mix of trusted first-party and untrusted third-party content in the same view, with a JavaScript bridge for native calls. Walk me through the risks and how you'd architect it safely.
What a strong answer covers: A strong answer flags that mixing trusted and untrusted content in one WebView with a shared JavaScript bridge is dangerous because any script running there, including a compromised ad, iframe, or injected third-party script, can call the bridge's exposed methods, extending the bridge's attack surface to every piece of content ever loaded. The safer architecture separates the WebViews: trusted content gets the bridge with JavaScript restricted to allowlisted first-party origins, untrusted content gets a separate WebView with no bridge and JavaScript disabled if possible, and every bridge method validates its inputs as if they came from an attacker.