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 / 15 completed
1 / 15
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 / 15
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 / 15
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 / 15
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 / 15
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.
6 / 15
Reviewer: 'This endpoint doesn't validate the user_id against any existing users in the database. It just allows any ID to be used.'
Which of the following actions would you recommend adding to this code review comment to address the potential security risk?
The reviewer correctly identifies a key vulnerability: lack of authorization. Option 'correct' proposes a fundamental security measure – validating the input against a known good source (the database) to ensure only authorized users can access the resource. Options 'insufficient' and 'incorrect' either misunderstand the severity or advocate for a flawed approach.
7 / 15
DevA (in Slack): 'Just pushing this new API key rotation script. It automatically rotates keys every 24 hours.'
Which statement best describes a potential security concern regarding this automated key rotation process?
While automated key rotation *can* improve security in some ways, it introduces significant operational risk. Option 'correct' highlights that frequent changes can lead to issues like service disruption if the process isn't robustly tested and monitored. Options 'incorrect' offer misleading assurances or ignore the potential downsides.
8 / 15
API Response (after a request to /users/{user_id}):
```json{
"status": "200",
"data": {
"user_id": "12345",
"username": "john.doe",
"email": "john.doe@example.com"
}
}```
Assuming this API is designed to protect user data, what's the most important security consideration regarding the user_id field in this response?
The core vulnerability here lies in exposing the raw user_id. Even though the API returns a successful 200 status code, the ID itself can be exploited if not properly secured. Option 'correct' accurately identifies this risk and suggests preventing direct exposure of sensitive identifiers.
9 / 15
PR Description: 'Implemented a new feature to allow users to upload profile pictures. Added validation for file types and sizes.'
Which of the following would be an *essential* addition to this PR description to further strengthen the security posture of this API?
While file size validation is a good start, it's not enough. Option 'correct' emphasizes the critical need for malware scanning – proactively detecting and preventing potentially harmful files from being stored on the server. This demonstrates a deeper understanding of security than simply validating file types and sizes.
10 / 15
Lead Developer (at Stand-Up): 'I'm working on implementing rate limiting for the API to prevent abuse. We're going with a tiered approach – higher tiers get more requests per minute.'
What is the primary security benefit of this tiered rate limiting strategy?
Tiered rate limiting specifically targets DoS attacks. By limiting the number of requests a user (or source) can make within a given timeframe, it prevents malicious actors from overwhelming the API and causing downtime or service disruption. Option 'incorrect' provides an oversimplified view of what rate limiting achieves.
11 / 15
Reviewer: 'This endpoint doesn't validate the user_id against any existing users in the database. It just allows any ID to be used.'
Which of the following actions would you recommend adding to this code review comment to address the potential security risk?
The reviewer correctly identifies a key vulnerability: lack of authorization. Option 'correct' proposes a fundamental security measure – validating the input against a known good source (the database) to ensure only authorized users can access the resource. Options 'insufficient' and 'incorrect' either misunderstand the severity or advocate for a flawed approach.
12 / 15
DevA (in Slack): 'Just pushing this new API key rotation script. It automatically rotates keys every 24 hours.'
Which statement best describes a potential security concern regarding this automated key rotation process?
While automated key rotation *can* improve security in some ways, it introduces significant operational risk. Option 'correct' highlights that frequent changes can lead to issues like service disruption if the process isn't robustly tested and monitored. Options 'incorrect' offer misleading assurances or ignore the potential downsides.
13 / 15
API Response (after a request to /users/{user_id}):
```json{
"status": "200",
"data": {
"user_id": "12345",
"username": "john.doe",
"email": "john.doe@example.com"
}
}```
Assuming this API is designed to protect user data, what's the most important security consideration regarding the user_id field in this response?
The core vulnerability here lies in exposing the raw user_id. Even though the API returns a successful 200 status code, the ID itself can be exploited if not properly secured. Option 'correct' accurately identifies this risk and suggests preventing direct exposure of sensitive identifiers.
14 / 15
PR Description: 'Implemented a new feature to allow users to upload profile pictures. Added validation for file types and sizes.'
Which of the following would be an *essential* addition to this PR description to further strengthen the security posture of this API?
While file size validation is a good start, it's not enough. Option 'correct' emphasizes the critical need for malware scanning – proactively detecting and preventing potentially harmful files from being stored on the server. This demonstrates a deeper understanding of security than simply validating file types and sizes.
15 / 15
Lead Developer (at Stand-Up): 'I'm working on implementing rate limiting for the API to prevent abuse. We're going with a tiered approach – higher tiers get more requests per minute.'
What is the primary security benefit of this tiered rate limiting strategy?
Tiered rate limiting specifically targets DoS attacks. By limiting the number of requests a user (or source) can make within a given timeframe, it prevents malicious actors from overwhelming the API and causing downtime or service disruption. Option 'incorrect' provides an oversimplified view of what rate limiting achieves.
What does "API Security Engineer — Technical Interview Questions in English" cover?
Practice answering API Security Engineer interview questions in professional English. 5 exercises covering OAuth 2.0, JWT, rate limiting, OWASP API Top 10, and threat modelling.
How many questions are in this interview set?
This set has 15 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.