---
title: API Security Interview Questions and Answers (2026)
description: Real API security interview questions — broken object level authorization, injection, rate limiting, secrets and the OWASP API Top 10 — with a prep plan.
url: https://usegreenroom.app/blog/api-security-interview-questions
last_updated: 2026-07-31
---
← Back to blog
Security
# API security interview questions and answers
July 31, 2026 · 12 min read
"Your endpoint is GET /api/orders/{id}," the interviewer said, "and it checks the JWT is valid before responding. What's wrong?" The candidate said nothing was — the user is authenticated. "Right. Authenticated as user 4021. Now they request order 4022." Which belongs to somebody else, and which the API cheerfully returns.
That is broken object level authorization, it is number one on the OWASP API Security Top 10, and it is the single most common real-world API vulnerability. API security interview questions circle it relentlessly because it catches people who conflate authentication with authorization. This guide covers that distinction, the rest of the OWASP list, and the practical controls interviewers expect you to name.
## What API security interviews actually test
API security interview questions appear in backend, platform, security engineer and senior full-stack loops. Five bands:
- AuthN vs AuthZ — the distinction above, and object-level checks.
- Input handling — injection, validation, mass assignment, deserialization.
- Resource protection — rate limiting, pagination limits, cost control.
- Data exposure — over-fetching, verbose errors, logging secrets.
- Operational security — secrets management, TLS, dependency risk, monitoring.
The five bands of API security interview questions, with object-level authorization the most-asked single topic.
## Authentication is not authorization
State the distinction cleanly: authentication establishes who the caller is; authorization establishes what that specific caller may do to that specific resource. A valid token proves the first and says nothing about the second.
So every handler that touches a resource by ID needs an ownership or permission check:
```
# WRONG — authenticated, but not authorized for THIS order
@app.get("/api/orders/{order_id}")
def get_order(order_id: int, user = Depends(current_user)):
return db.get_order(order_id)
# RIGHT — scope the query to the caller, do not filter after fetching
@app.get("/api/orders/{order_id}")
def get_order(order_id: int, user = Depends(current_user)):
order = db.get_order_for_user(order_id, user.id)
if order is None:
# 404, not 403 — do not confirm the record exists
raise HTTPException(404)
return order
```
Two details that score. First, push the ownership condition into the query rather than fetching and then comparing — the second form cannot be bypassed by a later refactor. Second, return 404 rather than 403 for a resource the caller may not see, because 403 confirms it exists and leaks information.
Related failures worth naming: broken function level authorization (an admin endpoint that only hides its button in the UI), and IDOR more generally. Predictable sequential IDs make exploitation trivial, so UUIDs help — but say clearly that UUIDs are defence in depth, not the fix. The fix is the check.
## Input handling: injection, validation and mass assignment
- SQL injection — still present. The answer is parameterised queries or an ORM, never string concatenation, and note that ORMs are not automatically safe when you drop into raw SQL.
- NoSQL injection — under-mentioned and worth points. In MongoDB, passing a JSON object where a string is expected lets an attacker inject operators like {"$ne": null} to bypass a login check. The fix is type validation before the query.
- Allowlist validation — validate type, length, format and range on every input, and reject rather than sanitise where you can. Denylists of bad characters always leak.
- Mass assignment — binding a request body straight onto a model lets an attacker set is_admin or account_balance. The fix is explicit input schemas per endpoint, which is why FastAPI's separate request models and Rails' strong parameters exist.
- Insecure deserialization — never deserialise untrusted data into arbitrary objects; Python's pickle on user input is remote code execution.
- SSRF — if your API fetches a user-supplied URL, an attacker can point it at internal services or cloud metadata endpoints. Allowlist destinations and block private IP ranges.
The general principle interviewers want stated: validate on the server, always. Client-side validation is user experience, not security, because the client is under the attacker's control. Our REST API interview questions guide covers the design layer.
## Rate limiting and resource consumption
Unrestricted resource consumption is high on the OWASP list and frequently forgotten. Expect "how would you stop someone brute-forcing the login endpoint?"
- Rate limit by identity and by IP, with tighter limits on sensitive endpoints — login, password reset, OTP, payment. A global limit is not enough.
- Know the algorithms — fixed window (simple, allows bursts at boundaries), sliding window (fairer, more state), token bucket (allows controlled bursts, the usual production choice), leaky bucket.
- Return 429 with Retry-After, and rate-limit at the edge (API gateway, Nginx, CDN) so the traffic never reaches your application.
- Cap pagination — an endpoint accepting ?limit=1000000 is a denial-of-service vector and a bulk-exfiltration tool.
- Limit request body size and query complexity — GraphQL specifically needs depth and cost limits, since a deeply nested query can be exponentially expensive.
- Add exponential backoff and lockout on auth endpoints, plus CAPTCHA where appropriate.
Our Nginx interview questions guide covers edge rate limiting concretely.
## Data exposure and error handling
APIs leak in quiet ways:
- Excessive data exposure — returning the full database record and letting the client hide fields. The client is not hiding anything; the data is on the wire. Use explicit response schemas.
- Verbose errors — stack traces, SQL fragments and library versions in a 500 response hand an attacker a map. Log the detail server-side with a correlation ID, return something generic.
- Secrets in logs — tokens, passwords and card numbers written to application logs, and tokens in URLs which land in access logs. Redact deliberately.
- User enumeration — "no account with that email" versus "wrong password" tells an attacker which emails are registered. Return identical responses and timing where practical.
- Missing security headers and permissive CORS — Access-Control-Allow-Origin: * combined with credentials is a real finding.
## Operational security
- Secrets management — never in code or committed .env files; use a secret manager (Vault, AWS Secrets Manager) or at minimum injected environment variables, and rotate. Expect "a secret was committed to Git — what do you do?" The answer is rotate first, then purge history — rotation is the urgent half, because the commit may already be cloned.
- TLS everywhere, including internal service-to-service traffic in a zero-trust posture, with HSTS at the edge.
- Dependency risk — automated scanning, prompt patching, lockfiles, and awareness of supply-chain attacks on packages.
- Least privilege — the database user for an API should not be able to drop tables; the service role should not have wildcard cloud permissions.
- Logging and detection — log authentication failures, authorization denials and rate-limit trips, and alert on patterns. An attack you cannot see is an attack you cannot stop.
- API inventory — undocumented, forgotten and unversioned endpoints are a top-10 item in their own right, because you cannot secure what you have forgotten exists.
## OWASP, PortSwigger, ChatGPT — where each fits
- The OWASP API Security Top 10 — read it once properly. Interviewers structure questions around it, and naming the categories precisely is a strong signal.
- PortSwigger Web Security Academy — free, hands-on labs including IDOR, SSRF and injection. The best practical preparation available, and you learn the attacker's view.
- OWASP cheat sheets — authorization, REST security and secrets management, all concise.
- Attacking your own API — highest yield. Build an endpoint, then change the ID in the URL and see what comes back. Everyone understands BOLA permanently after doing this once.
- Burp Suite Community or OWASP ZAP — worth an afternoon to see requests being modified in flight.
- ChatGPT — good for explaining a vulnerability class and reviewing code for obvious issues. It will not ask what happens when user 4021 requests order 4022.
- Greenroom — the spoken layer. Ari, the AI interviewer, runs security rounds out loud and pushes the "and what does that leak?" follow-up. Fair tradeoff: Ari does not pentest your API.
> The core truth: most real API breaches are authorization failures, not exotic cryptography. If every handler scopes its query to the caller and every response uses an explicit schema, you have prevented more incidents than any amount of header tuning.
## How to prepare for an API security interview
- Week 1: authorization. Build an endpoint with the BOLA bug, exploit it yourself, then fix it by scoping the query, and explain the 404-versus-403 choice aloud.
- Week 2: input handling. Work PortSwigger labs on injection, IDOR and SSRF, and implement explicit request schemas to prevent mass assignment.
- Week 3: resource protection and exposure — implement token-bucket rate limiting, cap pagination, and audit an API's responses for over-fetching and verbose errors.
- Final week: operational — secrets rotation, least-privilege database roles, security logging — then two full spoken mocks with security follow-ups.
Building the rest of the stack? The JWT and OAuth 2.0 guides cover the auth layer, the REST API guide covers design, and the cybersecurity analyst guide covers the defensive role.
## Frequently asked questions
### What are the most common API security interview questions?
The most common questions cover the difference between authentication and authorization and how broken object level authorization happens, how to prevent SQL and NoSQL injection, what mass assignment is and how explicit request schemas prevent it, how you would rate limit a login endpoint and which algorithm you would choose, how to avoid excessive data exposure and verbose error leakage, and how you handle secrets that were committed to a repository.
### What is broken object level authorization?
Broken object level authorization, or BOLA, happens when an API verifies that a caller is authenticated but never checks whether that specific caller may access the specific resource requested. A user authenticated as account 4021 requests order 4022 and receives it. It is the top item on the OWASP API Security Top 10 and the most common real-world API vulnerability. The fix is scoping every resource query to the caller's identity.
### Should you return 403 or 404 for a resource the user cannot access?
Return 404. A 403 confirms that the resource exists, which leaks information an attacker can use to enumerate valid identifiers, discover other users' records, or infer business data such as customer counts. Returning 404 makes an existing-but-forbidden resource indistinguishable from one that does not exist. Use 403 only where the user already legitimately knows the resource exists and simply lacks a permission.
### How do you prevent mass assignment vulnerabilities?
Never bind a request body directly onto a database model, because an attacker can include fields you never intended to be writable, such as an admin flag, a role, or an account balance. Define an explicit input schema per endpoint listing exactly which fields are accepted, and map from it deliberately. This is precisely why frameworks provide separate request models, strong parameters, or serializer allowlists.
### How would you rate limit a login endpoint?
Apply limits by both account identifier and source IP, with much tighter thresholds than general endpoints, and add exponential backoff or temporary lockout after repeated failures. Token bucket is the usual production algorithm because it permits controlled bursts while bounding sustained rate. Return HTTP 429 with a Retry-After header, and enforce it at the edge in an API gateway or reverse proxy so abusive traffic never reaches application servers.
### What should you do if a secret is committed to Git?
Rotate the secret first — that is the urgent action, because the commit may already have been cloned, forked, or scraped by automated bots within minutes. Only then purge it from history, revoke any sessions or tokens it issued, and audit logs for use of the credential. Afterwards add pre-commit secret scanning and move secrets into a proper secret manager so the same class of mistake cannot recur.
Security rounds are decided by the follow-up: and what does that leak? Greenroom runs mock backend and security interviews out loud with Ari and scores structure, clarity and depth. Free to start. Curious how it works? See how AI mock interviews work.