Top 30 API Security Interview Questions and Answers [2026]
October 3, 2026
14 min read
TL;DR: API security interviews in 2026 focus on authorization bugs first: object-level, function-level and property-level checks, which hold three places in the OWASP API Security Top 10. Candidates should also know OAuth with PKCE, how to limit resource use, and how to log attacks without logging secrets.
NIST published SP 800-228, Guidelines for API Protection for Cloud-Native Systems, in June 2025. It covers controls across the API life cycle, from design to runtime. The top risk has not moved.
Broken object level authorization, where an API checks who the caller is but not which records they may touch, has led the OWASP API Security Top 10 in both its 2019 and 2023 editions.
Key takeaways
1The 2023 OWASP API list merged Excessive Data Exposure and Mass Assignment into one risk: Broken Object Property Level Authorization.
2The 2025 OWASP Top 10 for web apps added Mishandling of Exceptional Conditions as a new category and folded SSRF into Broken Access Control.
3NIST SP 800-63B-4 (July 2025) sets a 15-character minimum for passwords used alone, and bans composition rules and forced periodic changes.
4RFC 9728 (April 2025) lets an API publish which authorization server protects it, and the MCP spec for AI agents requires it.
Authentication and Access
1. What is the difference between authentication and authorization in an API?
Authentication proves who the caller is; authorization decides what that caller may do. An API authenticates once per request, usually by checking a token. It must then authorize every action on every object.
Authorization failures fill three of the top five places in the OWASP API Security Top 10 2023. The caller is correctly identified, but the code never asks whether this caller may read this record or call this function.
2. When do you use the authorization code grant with PKCE, and when client credentials?
Use authorization code with PKCE when a user signs in and grants an app access. Use client credentials when a service calls an API on its own behalf, with no user.
PKCE (RFC 7636) binds the code to a secret the client made at the start of the flow, so a stolen code is useless. RFC 9700 now requires it for public clients such as SPAs and mobile apps.
Client credentials suit batch jobs and backend services. Their secret, or better a private key or certificate, must never ship in a client app.
3. What is the difference between OAuth 2.0 and OpenID Connect?
OAuth 2.0 is for authorization: it gives a client an access token for an API. OpenID Connect adds authentication on top: an ID token that tells the client who signed in.
A simple rule works in interviews. Use OAuth to call an API; use OIDC to log a user in. The ID token is for the client app, and an API should never accept it as an access token.
4. Are API keys enough to secure an API?
API keys identify a calling application, not a user, so on their own they are weak. They suit metering, quotas and simple server-to-server access, where the key can stay secret.
A key in a mobile app or browser bundle can be extracted, so treat it as public. Store keys hashed, let clients rotate them, give each key narrow permissions, and never put them in URLs, where they end up in logs.
For user data, use OAuth tokens instead.
5. How do OAuth scopes differ from user permissions?
Scopes limit what a client app may do for a user; permissions limit what the user may do at all. An API must check both, and the effective right is the overlap.
A user who is an admin may grant a reporting app only reports:read. That app must not delete users, even though the user could. A scope of invoices:read also does not mean the user may read every invoice.
The object-level check still applies.
6. Compare RBAC, ABAC and relationship-based access control.
RBAC grants rights to roles; ABAC decides from attributes of the user, resource and context; relationship-based control (ReBAC) decides from links between them, such as "member of this team".
RBAC: simple to audit. Breaks down when you need "editor, but only of their own region".
ABAC: flexible rules, such as department or data class. Harder to test and explain.
ReBAC: fits sharing models such as documents and folders. Usually needs a dedicated authorization service.
Most real systems mix them: roles for broad function access, and ownership or relationship checks for objects.
7. When should services authenticate each other with mTLS?
Use mTLS when services call each other and each side must prove its identity with a certificate. It stops an attacker on the internal network from calling a service directly.
A service mesh usually issues and rotates the certificates automatically. mTLS proves which service is calling. It does not say which user the call is for, so services still pass and check a user token for user actions.
OWASP API Top 10
8. What is BOLA, and how do you prevent it?
Broken object level authorization (BOLA) means the API returns or changes an object without checking that the caller may access that specific object. It is number one on the OWASP API Security Top 10 in both the 2019 and 2023 editions.
The attack is trivial: change /orders/1001 to /orders/1002. The fix is a check in every handler that loads an object by ID, ideally built into the data access layer so it cannot be forgotten:
// Scope the query to the caller instead of loading by ID alone
const order = await db.order.findFirst({
where: { id: req.params.id, accountId: req.user.accountId },
});
if (!order) return res.status(404).end();
Random UUIDs make IDs harder to guess, but they are not a fix. IDs leak through URLs, logs and shared links.
9. What is broken function level authorization?
BFLA means a user can call a function meant for another role, such as an admin endpoint. The endpoint checks that the caller is logged in, but not that they hold the right role.
Typical signs are admin routes under the same API as user routes, and a UI that hides the admin button while the API still accepts the call.
The fix is deny by default: every route declares the role or scope it needs, and a route with no rule fails closed.
10. What is broken object property level authorization?
It is the API reading or writing fields the caller should not touch, even on an object they may access. OWASP's 2023 list created this category by merging two 2019 risks: Excessive Data Exposure and Mass Assignment.
Reading too much (was API3:2019)
GET /users/me returns passwordHash or isAdmin
The client hides the fields, but anyone can read the raw response
Writing too much (was API6:2019)
PATCH /users/me with {"isAdmin": true}
Works because the handler binds the whole body to the model
The fix for both is explicit allowlists: response DTOs that name each returned field, and input schemas that reject unknown fields. See the API3:2023 entry.
11. What is unrestricted resource consumption, and how do you limit it?
It is any request that costs the server, or the company's bill, far more than it should. OWASP ranks it API4:2023. Rate limits alone do not cover it, because one request can be very expensive.
Controls include limits on page size, upload size, execution time, memory and GraphQL query cost. Add per-user rate limits and spending caps on paid third-party calls, such as SMS or LLM APIs.
An endpoint that sends a text message for free is a way to run up a bill.
12. How does SSRF happen in an API?
Server-side request forgery happens when the API fetches a URL the caller supplied, and the caller points it at an internal address. Common targets are cloud metadata endpoints and admin services that trust the internal network.
Webhooks, "import from URL" and image previews are the usual entry points.
Defenses: allow only the schemes and hosts you need, resolve the hostname and block private and link-local ranges, check again after redirects, and send outbound fetches through an egress proxy.
On AWS, requiring IMDSv2 blunts metadata theft.
13. What are unrestricted access to sensitive business flows?
These are flows that work exactly as coded but hurt the business when automated at scale, such as buying all tickets, creating thousands of accounts, or scraping prices. OWASP lists this as API6:2023.
No single request is invalid, so input validation cannot catch it. Defenses are about the flow: browser fingerprinting, human checks at key steps, per-account and per-card limits, and alerting on unusual rates.
The first step is to name which flows would hurt if a bot ran them.
14. Why is API inventory a security problem?
You cannot protect an endpoint you do not know exists. OWASP renamed this risk from Improper Assets Management (2019) to Improper Inventory Management (API9:2023).
The classic case is an old /v1 still running beside /v2, without the fixes /v2 got. Others are staging hosts on the public internet and forgotten partner APIs.
Keep a machine-readable spec for every API, compare it with real gateway traffic, and retire old versions on a date you publish.
15. What does "unsafe consumption of APIs" mean?
It means trusting data from third-party APIs more than you trust user input. OWASP lists it as API10:2023.
A partner API can be compromised, or simply return something odd.
Validate its responses against a schema, set timeouts, do not follow redirects blindly, and never pass its data into SQL, shell commands or HTML without the same encoding you use for user input.
Input, Browsers and Protocols
16. How do you prevent injection in an API?
Keep data and code apart: parameterized queries for SQL, safe query builders for NoSQL, and argument arrays instead of shell strings.
# Python, psycopg: the driver sends the value separately from the SQL
cur.execute("SELECT * FROM users WHERE email = %s", (email,))
Then validate input against a schema: types, lengths and allowed values. Injection no longer has its own entry in the 2023 API list, but it is still A05 in the 2025 OWASP Top 10 for web apps.
In NoSQL stores, watch for operator injection, where a JSON body sends {"$ne": null} instead of a string.
17. What does CORS protect, and what does it not?
CORS lets a server tell browsers which other origins may read its responses. It protects users' browsers, not the server. Any script, curl command or backend can still call the API.
So CORS is never an access control. The two common mistakes are reflecting any Origin back with Access-Control-Allow-Credentials: true, and trusting null as an origin. Both let a hostile site read a logged-in user's data.
Yes, if the browser sends its credentials automatically, which means cookies. An API that only accepts a bearer token in the Authorization header is not exposed to classic CSRF, because a forged cross-site request cannot add that header.
For cookie-based APIs, set SameSite=Lax or Strict. Then add a CSRF token or check the Origin header on state-changing requests. The OWASP CSRF cheat sheet covers the options.
19. How would you secure a file upload endpoint?
Treat every uploaded file as hostile: limit it, check it, store it away from code, and serve it from another domain.
Enforce a size limit before reading the whole body.
Check the type from the file's content, not the name or the client's Content-Type.
Rename files to server-generated names, which blocks path traversal.
Store them in object storage, never in a folder the web server can execute.
Scan for malware where the risk calls for it, and serve files from a separate domain with Content-Disposition: attachment.
Return a consistent, minimal error body and keep the details in server logs. Stack traces, SQL errors and internal hostnames in responses help attackers map the system.
RFC 9457 defines a standard JSON shape, application/problem+json, with type, title, status and detail. Also watch that errors do not reveal what exists. A login that answers "no such user" for some emails lets attackers list accounts.
21. What security problems are specific to GraphQL?
One endpoint accepts arbitrary queries, so cost control and field-level authorization move into the GraphQL layer.
Expensive queries: deep nesting and large lists. Limit depth and compute a cost per query.
Batching: many operations or aliases in one request can bypass per-request rate limits, for example to brute-force a login.
Authorization per field and per object: in resolvers or a shared layer, not only on the endpoint.
Introspection: often turned off in production. That hides the schema but is not a security control.
Authenticate the handshake, check its Origin, use wss://, and authorize each message. The browser WebSocket API cannot set an Authorization header, so teams use a cookie or a short-lived ticket.
A token in the query string works but lands in proxy and server logs. A safer pattern is a one-time ticket: the client gets it from a normal authenticated call, then sends it on connect.
With cookies, the Origin check matters because browsers do not apply CORS to WebSockets. Long-lived connections also need to recheck access when a token expires or a user is removed.
Detection and Testing
23. What should an API log for security, and what must it never log?
Log security events with enough context to investigate; never log secrets or sensitive personal data.
Useful events are logins and failures, authorization denials, admin actions, permission changes and input validation failures. Each needs a timestamp, user or client ID, source IP and a request ID.
Never log passwords, tokens, API keys, full card numbers or session cookies. Watch for them in request dumps and error traces, where they slip in by accident. The OWASP Logging cheat sheet has a fuller list.
24. How do you detect and slow credential stuffing?
Credential stuffing tries leaked username and password pairs against your login API. It shows up as many accounts failing from shared IPs or devices, and as a login success rate far below normal.
Defenses work in layers: rate limits per account and per IP range, checks of new passwords against breached-password lists, MFA, and bot detection at the login step.
Lockouts should be temporary and graded, or attackers can use them to lock real users out.
25. How do you test an API's security before release?
Combine automated checks in CI with tests that know your authorization rules. Scanners find missing headers and injection; they rarely find BOLA, because they do not know who should own what.
In CI: dependency and secret scanning, static analysis, and a lint of the OpenAPI spec for missing auth.
Authorization tests: for each endpoint, call it as a different user and as a lower role, and expect 403 or 404.
Fuzzing: generate requests from the OpenAPI spec to find crashes and unhandled input.
Before major releases: a manual penetration test focused on business logic.
What Changed Recently
Jan 2025
RFC 9700: OAuth 2.0 Security Best Current Practice
Apr 2025
RFC 9728: OAuth 2.0 Protected Resource Metadata
Jun 2025
NIST SP 800-228: Guidelines for API Protection for Cloud-Native Systems
Jul 2025
NIST SP 800-63-4 replaces 800-63-3 for digital identity
2025
OWASP Top 10:2025 for web applications
26. What changed in the OWASP Top 10:2025?
The 2025 edition has two new categories and one merge. Broken Access Control stays at A01, and SSRF is now part of it.
A02 Security Misconfiguration rose from fifth in 2021.
A03 Software Supply Chain Failures expands the old vulnerable components category to dependencies, build systems and distribution.
A10 Mishandling of Exceptional Conditions is new: improper error handling, logic errors and "failing open".
For APIs, A10 is the one to probe in interviews. Ask what the service does when the authorization service times out. The right answer is to deny, not to let the request through.
Two different lists. The OWASP Top 10 covers web applications and was updated in 2025. The OWASP API Security Top 10 is a separate project whose current edition is 2023. Candidates often mix up their numbering.
27. What does NIST SP 800-228 add for API teams?
It gives a checklist of API risks and controls across the life cycle, from design and build to runtime. SP 800-228, published in June 2025, splits controls into those applied before runtime and those at runtime.
It also compares the pros and cons of different ways to implement each control.
For interviews, it gives a shared vocabulary for questions like "where would you enforce this?" and "which controls belong before deployment?". A candidate who has read it can map a control to a stage of the API life cycle.
28. What do NIST's 2025 password rules mean for a login API?
SP 800-63B-4 requires passwords used alone to be at least 15 characters, and at least 8 when used as part of MFA. Verifiers "SHALL NOT impose other composition rules" and "SHALL NOT require subscribers to change passwords periodically".
A change is required only on evidence of compromise.
It also says verifiers "SHALL offer at least one phishing-resistant authentication option at AAL2", such as passkeys.
For a login API, that means dropping character-mix rules, checking new passwords against a blocklist of breached and common passwords, and supporting WebAuthn.
29. What does RFC 9700 change for API security?
RFC 9700, published in January 2025, is the IETF's OAuth 2.0 security best practice. It makes PKCE mandatory for public clients. It says clients should not use the implicit grant, and must not use the password grant.
It also says access tokens should be limited to the specific APIs and actions they are needed for, and refresh tokens for public clients must be sender-constrained or rotated.
For an API team, the practical checks are audience restriction and narrow scopes on every token.
30. What is RFC 9728, and why do AI agent protocols use it?
RFC 9728 lets an API publish metadata about itself, including which authorization servers issue tokens for it. It lives at /.well-known/oauth-protected-resource.
An API can also point to it from a WWW-Authenticate header on a 401, so a client that knows nothing in advance can find out how to get a token.
The MCP authorization spec (version 2026-07-28) says MCP servers "MUST implement" it. It also requires clients to send the RFC 8707 resource parameter, so each token is bound to one server.
That audience binding stops a token issued for one tool server from being replayed against another.
Signs of a Strong Answer
They put object-level checks in the data access layer, and do not rely on hard-to-guess IDs or the gateway.
They name the 2023 OWASP API categories correctly, including property-level authorization, and give an example from their own work.
They separate scopes from user permissions and check both.
They describe authorization tests that call each endpoint as the wrong user, not just scanner runs.
They make failures deny by default, including when an auth dependency times out.
They know which log fields leak secrets in their stack, such as request bodies and headers in error traces.
Hiring API Security Talent
Authorization bugs are logic bugs, so the engineers who prevent them are the ones who build the APIs. Second Talent matches companies with pre-vetted API developers and back-end engineers from Asia, screened with questions like these.
Tell us the stack and we send a shortlist within 24 hours. Start hiring, or see our OAuth and JWT interview guides.
Ready to hire?Hire API Developers: vetted AI-native talent, with first profiles in 24 hours.
