Practice answering API Security Engineering interview questions in professional English. 5 exercises on OAuth 2.0, JWT validation, rate limiting, OWASP API Top 10, and mTLS.
What separates good from great API security answers
Name the attack vector: "BOLA allows access to other users' objects" beats "it's an auth issue"
Explain the mechanism: why does JWT alg:none work? what does it bypass?
Defence in depth: one control is never enough — layer them
OWASP API Top 10: know it by number — API1 through API10
0 / 5 completed
1 / 5
The interviewer asks: "What is the difference between OAuth 2.0 and OpenID Connect, and when would you use each?" Which answer is the most precise?
Option C is the strongest: defines OAuth 2.0's purpose precisely (delegated API access, resource owner authorisation), explains what OIDC adds (ID token as JWT with specific claims, UserInfo endpoint), gives a concrete use case for each, and most importantly warns against the common mistake of using access tokens for identity — explaining exactly why (access tokens are opaque, format not standardised). Option A is correct but has no mechanism or common pitfall. Option B is factually wrong — OIDC is not a new version of OAuth. Option D is superficially correct but adds SAML tangentially without adding insight about the OAuth/OIDC distinction.
2 / 5
The interviewer asks: "What is BOLA and how do you prevent it in an API?" Choose the most complete answer.
Option B is the strongest: names the OWASP ranking (API1), explains the exact mechanism (authentication is checked but object-level authorisation is skipped), specifies where the ID can appear (path parameter, query string, body), gives the precise prevention rule (compare authenticated principal ID with resource owner_id), adds the non-obvious architectural point (service layer check vs database query and ORM bypass risk), and describes automated testing to prevent regressions. Option A is minimal. Option C is accurate but offers no mechanism. Option D mentions UUIDs — which reduce guessability but do not prevent BOLA if authorisation is not checked — making it a common misconception that the strongest answer avoids.
3 / 5
The interviewer asks: "What JWT vulnerabilities should every API developer know about?" Which answer is the most comprehensive?
Option A is the strongest: names three specific, mechanistically distinct attacks (algorithm confusion with the public-key-as-HMAC-secret exploit explained precisely, alg:none bypassing signature verification, weak secret offline brute-force), gives a concrete mitigation for each, and adds an architectural recommendation (asymmetric algorithms for multi-service). Option B mentions weak secrets and expiry — important but only one of the three attack classes. Option C is best-practice advice without any attack mechanism. Option D mentions replay attacks (a real concern) but does not explain the algorithm attacks that are the most common JWT interview topic. Knowing the mechanism of each attack is what separates a security engineer from a developer who has read a checklist.
4 / 5
The interviewer asks: "How do you design rate limiting for a public API?" Choose the answer that shows the most architectural depth.
Option B is the strongest: structures the answer around four explicit design decisions (limit unit, algorithm, enforcement point, response format), explains the trade-offs of each algorithm (token bucket vs sliding window vs fixed window and their respective weaknesses), distinguishes unauthenticated from authenticated rate limiting with the reason (IP limiting is ineffective against distributed clients), and adds the operational requirement (Redis-backed, configurable without redeployment for incident response). Option A is the minimal answer. Option C correctly describes token bucket with Redis but only covers the algorithm decision — not unit selection, enforcement point, or response design. Option D names real tools but treats rate limiting as a configuration task rather than a design problem.
5 / 5
The interviewer asks: "What is mTLS and when would you require it for API security?" Which answer shows the most practical understanding?
Option C is the strongest: defines mTLS precisely (client certificate in TLS handshake, validated against CA or pinned identity), contrasts it with bearer tokens and explains why it is stronger (cryptographic vs possession-based), gives two specific use cases with justification (zero-trust service mesh, high-privilege APIs), names the operational challenge precisely (certificate lifecycle and rotation failure as outage), and gives a concrete operational solution (Istio or Vault, 24-hour TTL short-lived certificates). Option A is correct but superficial. Option B makes the factually wrong claim that most APIs use API keys instead — mTLS and API keys are not mutually exclusive, and many service meshes use mTLS by default. Option D mentions the right use case (internal microservices) and notes the PKI requirement but has no depth on why or how.