Practise answering 5 interview questions for an API Security Engineer role in professional English. Compare different answer quality levels and understand what distinguishes surface-level security knowledge from the depth an interviewer expects.
How senior API security answers are structured
Explain the mechanism: don't just name the vulnerability — explain how the attack works step by step
Specific mitigations: vague "validate everything" is weak; name the exact library config, header, or code pattern
Threat model: for each defence, say what it protects against — a mitigation without a named threat is incomplete
Operational reality: mention rotation, audit logging, and revocation — security without operations fails at scale
0 / 5 completed
1 / 5
The interviewer asks: "Walk me through the OWASP API Security Top 10. Which three items do you consider the highest risk in practice, and why?" Which answer demonstrates the best command of API security?
Option B is the strongest: it lists all 10 items (showing full familiarity), then justifies three with specific technical reasoning — BOLA with the developer assumption trap and scanner limitation, Function Level Auth with the HTTP method axis and vertical privilege oversight, and Resource Consumption with the DoS and pagination threats. Option C is excellent — CORS wildcard misconfiguration and shadow endpoints are exactly the kind of operational detail that shows real experience. It would be a strong answer in a real interview. Option D correctly identifies shadow APIs under improper inventory management — a sophisticated observation rarely given. Option A is too vague — "injection attacks" doesn't appear in the 2023 OWASP API Top 10 by that name, which would concern an interviewer. Senior answer structure: demonstrate breadth (know the full list) → pick three with specific exploitation mechanics → include developer failure pattern (why it happens) → include detection difficulty.
2 / 5
The interviewer asks: "Explain the 'alg:none' JWT attack. How do you defend against it, and what other JWT vulnerabilities should an API security engineer know?" Choose the most technically accurate answer.
Option B is the strongest: it explains the exact mechanics of alg:none (decoding/re-encoding the header, stripping the signature), explains why it works (server reads alg from the header instead of enforcing server-side), gives the precise fix (hardcode the algorithm in verification logic), and then covers four additional JWT vulnerabilities with mechanisms and mitigations — including the sophisticated algorithm confusion attack and the kid header injection. Option C is an excellent concise answer that covers the core fix and names the four key risk categories — this would pass a real interview. Option D makes a good practical point about library CVEs (several HS256 libraries like node-jsonwebtoken had alg:none vulnerabilities for years), but doesn't explain the mechanics. For security questions at senior level: explain the attack mechanics ("how does this actually work") → give the precise defence → add the related attack variants → quantify or name specific libraries/standards where possible.
3 / 5
The interviewer asks: "Compare OAuth 2.0 grant types from a security perspective. Which would you recommend for a mobile application, and why?" Which answer shows the most secure design thinking?
Option B is the strongest: it covers all five grant types with precise security profiles, explains why Implicit was deprecated (referrer, history, JS access — not just "it's old"), distinguishes PKCE technically (code verifier/challenge pair mechanism), names the mobile-specific detail (system browser isolation), explains why no client secret in mobile binary (decompiling), and covers rotating refresh tokens as a theft detection mechanism. Option C is an excellent practical answer and would pass most senior interview bars — it covers the key points concisely without fluff. Option D adds the open redirector attack (redirect URI validation) which is a good addition rarely mentioned. Option A is technically correct but shallow — "Implicit is outdated" without knowing why is not sufficient at senior level. For OAuth questions: cover each type's threat model → justify the recommendation with the mobile-specific constraints → include the refresh token theft detection mechanism.
4 / 5
The interviewer asks: "Describe two rate limiting algorithms — token bucket and sliding window — and explain which you'd choose for a public API and why." Which answer best explains both algorithms and the trade-off?
Option B is the strongest: it explains both algorithms with concrete parameters (100 tokens, 10/s, 60 req/60s), explains the burst mechanic for token bucket and why it models realistic use well (batch → idle pattern), explains the throughput guarantee advantage of sliding window, covers the implementation complexity (Redis sorted sets), and gives a concrete recommendation with a use-case justification for each — plus a bonus mention of leaky bucket. Option C is an excellent practical answer — the "developer-friendly" framing with the user-action burst use case is exactly the right reasoning for a public API. Option D adds excellent extra points: the fixed window boundary problem (a common interview follow-up) and credential stuffing as a global rate limit motivation. Option A is technically correct but too shallow for a senior API security role. Key differentiation: articulating that token bucket models realistic client behaviour patterns (not just "it allows bursting") is what separates a strong answer from a superficial one.
5 / 5
The interviewer asks: "Compare mTLS and API key authentication for securing service-to-service communication. When would you choose each?" Which answer demonstrates the most nuanced security thinking?
Option B is the strongest: it defines both mechanisms precisely (API key weaknesses: static, no identity binding, log leak risk; mTLS strengths: cryptographic identity, automated rotation via SPIFFE/SPIRE or Vault PKI), compares them on three dimensions (identity guarantee, operational cost, PKI requirement), gives specific use cases for each, and ends with a concrete operational rule (scope API keys to minimum permissions). Option C is excellent and gives a very clean, practical comparison — the SPIFFE/SPIRE reference and internal PKI joining problem for external partners are exactly the right points. Option D adds the revocation distinction (CRL/OCSP for certs vs. no auto-detection for leaked API keys) and the URL parameter security anti-pattern — both excellent operational points. Option A is too binary ("mTLS is more secure") without explaining why or when each is actually the right choice. For this comparison: explain the identity model of each → weaknesses of each → operational requirements → concrete use-case decision rule → add the "never in URL query params" API key rule.