Network Security Interview Questions
SECURITY › Security
Walk me through the actual attack a MITM performs against an app that does plain HTTPS with no pinning. What does the attacker need, and why doesn't HTTPS alone stop them?
What a strong answer covers: A strong answer walks through the attacker needing a certificate trusted by the device's trust store, most commonly by getting a malicious or enterprise CA installed, or exploiting a compromised or misissued public CA, then positioning on the network path to intercept and re-encrypt traffic with that cert. Standard TLS validation only checks the chain leads to some trusted root plus hostname match, so if a rogue CA is trusted, the client accepts the MITM's certificate transparently; pinning defends against exactly this scenario, which plain HTTPS's chain-of-trust model doesn't stop on its own.
When would you actually recommend certificate pinning for a production app, versus when is it more risk than it's worth? What's the failure mode that makes teams rip pinning back out?
What a strong answer covers: Pinning fits high-value targets, banking apps, apps handling sensitive PII, or apps operating where state-level MITM risk is real, where the operational cost of maintaining pins is justified; for most consumer apps, standard TLS with a solid CA chain is sufficient and pinning's rotation risk outweighs the benefit. A strong answer names the classic failure: teams pin without backup pins or an expiration and kill-switch plan, a cert rotates, and the app locks itself out of its own backend for every installed user until a new release ships.
A teammate wants to store a third-party API key in the app, arguing R8 obfuscation will protect it so you can skip building a token-issuing endpoint. Walk me through how you'd talk them out of it and what you'd build instead.
What a strong answer covers: A strong answer explains R8 only renames symbols and doesn't encrypt strings or block decompilation or runtime inspection; anyone can pull the APK, decompile it, or hook the running process to extract the key regardless of obfuscation, so any secret embedded client-side is effectively public. The right fix is a backend proxy that holds the real key server-side and issues short-lived, scoped tokens, or performs the third-party call itself, so the client never possesses a credential worth stealing.