5 exercises — choose the best-structured answer to common API Security Engineer interview questions. Focus on precise vocabulary, correct use of technical terms, and demonstrating real experience.
Structure for API Security answers
Tip 1: OAuth 2.0 flows: Authorization Code + PKCE for web/mobile, Client Credentials for M2M
Tip 2: JWT pitfalls: alg:none attack, RS256 vs HS256, short expiry + refresh token rotation
Tip 3: OWASP API Top 10 2023: Broken Object Level Auth, Broken Auth, Broken Object Property Level Auth
Tip 4: Threat modelling: STRIDE per API endpoint, trust boundary diagram, attack surface mapping
0 / 5 completed
1 / 5
The interviewer asks: "Explain the difference between OAuth 2.0 Authorization Code flow and Client Credentials flow." Which answer best demonstrates OAuth 2.0 expertise?
Option B is strongest because it defines both flows precisely, explains PKCE and why it is needed, and gives the correct use case for each. Key structure: Authorization Code + PKCE (human user, consent, code exchange, refresh token) vs. Client Credentials (M2M, no user, direct token, no refresh token). Option A confuses the user-agent type with the flow selection criteria. Option C is incorrect — both flows can produce JWTs or opaque tokens depending on the authorization server configuration. Option D is a common misconception — both flows have their own security trade-offs.
2 / 5
The interviewer asks: "What are the most common JWT security vulnerabilities?" Which answer best demonstrates JWT security depth?
Option B is strongest because it identifies five distinct, technically precise vulnerabilities with specific attack mechanisms and concrete mitigations for each. Key structure: alg:none → algorithm whitelist; RS256/HS256 confusion → per-audience enforcement; weak secret → asymmetric keys; long expiry → short TTL + rotation; base64 ≠ encryption → JWE. Option A is false — JWTs are widely used securely when implemented correctly. Option C identifies only transport security, missing all JWT-specific vulnerabilities. Option D confuses token expiry with revocation — expired tokens cannot be revoked mid-TTL.
3 / 5
The interviewer asks: "What is Broken Object Level Authorization and how do you prevent it?" Which answer best demonstrates OWASP API Top 10 knowledge?
Option C is strongest because it defines BOLA precisely, gives a concrete example, provides a correct DB-level prevention pattern with actual SQL, and adds the important caveat that UUIDs alone are not a fix. Key structure: API accepts ID without ownership check → attacker changes ID → accesses others' data; fix: WHERE id=? AND user_id=? + no trust on client IDs + automated swap-token CI tests. Option A describes Excessive Data Exposure (OWASP API #3), not BOLA. Option B correctly describes the guessability vector but treats UUIDs as the primary fix — they are not. Option D is dangerously wrong — BOLA affects all endpoints that accept object IDs.
4 / 5
The interviewer asks: "How do you implement rate limiting for an API that has multiple tiers of users?" Which answer best demonstrates tiered rate limiting design?
Option B is strongest because it applies rate limiting at each relevant layer with concrete quota examples, uses the correct algorithm (sliding window over fixed window), and includes the client-facing response contract. Key structure: per-IP (unauthenticated) → per-key/user (tier quotas) → per-endpoint (expensive ops) → sliding window → RFC 7807 + Retry-After headers. Option A applies a single blanket limit, which cannot support tiered pricing models. Option C relies entirely on a black-box gateway without understanding the tiering requirements. Option D is client-side only and provides no server-side protection.
5 / 5
The interviewer asks: "How do you approach threat modelling for a new API?" Which answer best demonstrates security engineering process?
Option B is strongest because it applies STRIDE systematically to each threat category, maps each category to a concrete control, and describes the process artefacts (trust boundary diagram, risk rating, living document). Key structure: STRIDE per endpoint → trust boundary diagram → likelihood × impact risk rating → mitigations → updated on each major change. Option A (pen testing in production) is too late — security should be designed in, not bolted on. Option C (OWASP Top 10 checklist) is a useful reference but not a threat modelling methodology. Option D (code review) is valuable but does not systematically enumerate threats.