Security interview questions
Security questions a Mobile developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
When do you ask for camera permission?
The strongest answer: The moment the user chooses an action that needs the camera, with one line on why — never as a pile of dialogs on first launch
Why it works: Exactly. Context plus a reason is how people grant — and how stores review the prompt.
- Ask in context, with a reason.
- Do not batch dangerous permissions on first launch.
- Purpose strings must match the actual use.
- A denied-forever path needs a settings deep link, not a retry loop.
A junior wants to “add certificate pinning to everything” this week. What is the right first move?
The strongest answer: TLS to your real hosts is the default; pinning is an extra control with a rotation plan — do not pin until we can ship a pin change without bricking the app
Why it works: Exactly. HTTPS first. Pinning without rotation is how you lock users out on the next cert renew.
- HTTPS / ATS is the baseline.
- Pin only hosts you can rotate.
- Have a break-glass (config, new build).
- Never pin a CDN you do not operate.
A partner API needs a secret key, and a teammate puts it in a constants file in the app. What do you say?
The strongest answer: Anything shipped inside the app can be read out of it, so that key is public the day we release. Call the partner from our own backend and let the app talk to our server instead
Why it works: Exactly — the client is not a place secrets can live, so the fix is architectural: the secret stays server-side.
- Anything shipped is public.
- Secrets live on the server.
- Proxy the partner call through your backend.
- Obfuscation is not protection.
You will pin your API. What else ships in the same change?
The strongest answer: Backup pins or a remote pin set, a monitored expiry, and a way to ship a new pin before the old cert dies — plus a debug escape for the team, not for production users
Why it works: Exactly. Pinning is an operations feature. Rotation is the feature.
- Ship backup / remote pins.
- Watch expiry.
- Do not pin third parties.
- Do not offer “turn off TLS.”
Camera grant rate is poor and denied-forever is high. How do you work it?
The strongest answer: I treat it as a funnel: pre-prompt education, ask in context, a settings recovery path, and I measure grant / deny / forever — I do not spam the system dialog
Why it works: Exactly. Education, context, recovery, measurement. No second system dialog.
- Measure the permission funnel.
- Educate, then ask.
- Deep-link to settings after forever.
- Do not fake system UI.
A pin mismatch will brick the app on a bad deploy. What is your break-glass?
The strongest answer: A remotely updatable pin set signed by us, plus the ability to ship a store build that relaxes to a new pin — I do not hide an unsigned “trust any cert” flag in production
Why it works: Exactly. Signed remote pins and a real store train. Not a silent TLS downgrade.
- Signed remote pin updates.
- A store build as last resort.
- No production “trust any.”
- No HTTP fallback.
You need to prove the device still holds a user key after a biometric. Where does the key live?
The strongest answer: In hardware-backed Keystore / Secure Enclave, used via an API that never exports the private key — biometrics gate use, they are not the key
Why it works: Exactly. Hardware-backed, non-exportable, biometric as a gate.
- Hardware-backed key, no export.
- Biometric gates use.
- Do not duplicate the private key to the server “for speed.”
- Do not keep it in JS / Dart state.
A support engineer pastes a crash log into a ticket. It contains a user’s full address and part of a card number.
What do you put in place?
The strongest answer: A rule about what may ever be logged, enforced where the logging happens: sensitive fields redacted at the source, crash reports and breadcrumbs scrubbed, and sensitive screens hidden from the app-switcher snapshot
Why it works: Right — redaction has to happen at the point of logging, or the next feature reintroduces it a month later.
- Redact where you log.
- Name what may never be logged.
- Scrub crash reports and breadcrumbs.
- Hide sensitive screens from snapshots.
A security review asks what you assume about a rooted / jailbroken phone. What is a sane answer?
The strongest answer: The device is hostile: I protect tokens in hardware-backed storage, pin what we can rotate, minimise secrets on device, and I do not pretend root detection is a wall — I design so a stolen phone is a bounded incident
Why it works: Exactly. Hostile device, bounded blast radius, no faith in root theatre.
- Assume a hostile device.
- Hardware-backed keys, few secrets.
- Root detection is extra, not the control.
- Bound what a stolen phone can do.
When does the org require certificate pinning?
The strongest answer: On the few hosts that carry high-value sessions, with a rotation runbook and an owner — not “pin the internet,” and not “never pin because it is hard”
Why it works: Exactly. Pinning is a scoped control with an owner. Ideology either way is how you brick or leak.
- Scope pins to high-value hosts.
- Name an owner and a rotation.
- Do not pin third parties.
- Do not leave it as a debug toy.
Growth wants a new attribution SDK that wants IDFA, a full photo dump, and its own WebView. What is the bar?
The strongest answer: A security and privacy review with a default of no, a data-flow diagram, and a measured product upside — I will not add a second WebView and a photo dump for a dashboard
Why it works: Exactly. SDKs are attack surface and privacy surface. Upside must beat that, in writing.
- Review SDKs like you review features.
- Default no for photo + IDFA + WebView.
- Measure the upside.
- Do not hide an SDK from one store.