mobile security

A single check is a single patch. The design question is how to make removing protection expensive, detectable at scale, and pointless because the server holds the real decisions.

Short-range radio assumes that being close means being trusted. The scored answer explains pairing models, key negotiation bugs and why relays need distance measurement, not stronger encryption.

Both platforms sandbox apps and require signing; they differ in who decides what runs and how fast fixes arrive. Interviewers want the shared model first, then the differences that change a threat model.

The sandbox is a Linux user ID, SELinux and a signature that decides who you are. Get those three right and most Android security questions become reasoning rather than recall.

A standard is a checklist only if you use it badly. The answer interviewers want maps the app's data and threats onto MASVS areas, then picks which MASTG tests are worth the time.

'Use the Keychain' is half an answer. Interviewers check whether you know the key never leaves the hardware, the data it protects still does, and which settings stop it riding along in a backup.

Every exported component is an API that any app on the phone can call. The vulnerabilities are the same ones you know from web APIs: missing authorization, trusted input, and a confused deputy.

Any app can claim myapp://. That single fact breaks OAuth redirects, password-reset links and payment flows that trust a custom scheme. The fix is a link the operating system verifies against your domain.

A WebView puts a browser inside your app, without the browser's address bar, and often with a bridge to native code. XSS in that page is no longer 'just XSS'.

The token is safely in the Keychain, and also in the crash log, the analytics payload and the app-switcher screenshot. Interviewers want the list of side doors, not the front door again.

The device is in the attacker's hand in half the scenarios. A strong model sorts threats by where the attacker sits, then puts every decision that moves money behind a check the phone cannot fake.

Pinning narrows trust, and every outage story about it is a rotation story. The scored answer decides whether to pin at all, pins public keys with backups, and plans for the release that can never update.

Two different questions hide here: does the app validate TLS at all, and does it pin? Testers who merge them either miss the critical bug or report a non-issue as one.

Detection that runs on the attacker's device reports whatever the attacker allows it to. Interviewers want to hear what it is still good for, and what it must never decide alone.

Attestation gives your server a signed statement it did not have to trust the client for. The design question is what that statement covers, how you bind it to a request, and what you do when it is missing.

Anything in the app binary belongs to whoever downloads it. The strong answer stops trying to hide a client secret and builds on user tokens, PKCE, device-bound keys and server-side limits.

Unzip, decompile, read the manifest, then watch it run. The interview checks whether you know where the interesting parts of an app hide, and that obfuscation changes your effort, not your conclusions.

Moving a secret into C changes who can find it in an afternoon, not whether it can be found. The scored answer shows how an analyst would recover it, then replaces the design with one that does not need a shared secret.

No shield is unbreakable, so 'can it be bypassed' is the wrong test. Measure how much it raises an attacker's cost on the threats you actually face, and what it costs you in crashes, performance and false positives.

Everything shipped on the phone belongs to the person holding it: the weights, the system prompt and any key the assistant uses. And the assistant now reads notifications, messages and screens written by strangers.

Pinning protects the user from the network. It was never going to protect your API from the person holding the phone, and the good answer explains both halves.

A key the app cannot export is only half the story. The other half is making the key usable only after the user is really present, which a hooked 'authentication succeeded' callback can fake.

On a phone, the signing key is the app's identity: it decides who can ship updates, which data the app can share, and what it is entitled to do. Lose it, or let someone else sign, and that identity changes hands.

Employees will read company email on their own phones either way. The scored answer protects the data without owning the device, and is honest about what IT can and cannot see.

Spyware chains usually arrive through features most people never use. The scored answer trades those features away for the people who need it, and plans for what happens when protection is not enough.