yoklainterview sim
ProgressHistory

Security As Api Security Interview Questions

75 verified Security As Api Security interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

As Api SecurityDifficulty 1
A public API endpoint has no limit on how many requests a single client can send per minute. What is the main security risk this creates?
  • aA client can hammer the endpoint for brute force, scraping, or resource exhaustion✓
  • bTLS certificates will expire faster under high load
  • cThe API will return stale cached data to every client
  • dThe database schema becomes visible in error messages
Explanation:Without rate limiting, nothing stops a single client (or botnet) from sending unbounded requests — enabling credential brute forcing, content scraping, or simply exhausting server/database resources (a DoS-like effect).
As Api SecurityDifficulty 1
A rate limiter counts requests per client IP address. Why is IP-based rate limiting alone often insufficient for authenticated API users?
  • aIP addresses are always encrypted end-to-end at the transport layer, so no server-side rate limiter component can ever inspect or key off them for counting purposes.
  • bShared IPs group unrelated users, and attackers can rotate IPs to evade the limit.✓
  • cHTTP/2 forbids servers from reading the client IP address
  • dIPv6 addresses cannot be stored in a rate-limiting counter
Explanation:IP-based limits have two failure modes: shared IPs (office NAT, mobile carrier CGNAT) group unrelated users under one counter, while attackers with many IPs (proxies, botnets) simply spread requests to stay under any single-IP threshold. Keying the limiter by authenticated user/API key (in addition to or instead of IP) avoids both problems.
As Api SecurityDifficulty 2
An API returns HTTP 429 with a Retry-After header when a client exceeds its rate limit. A well-behaved client should:
  • aBack off and wait at least the duration given in Retry-After before retrying✓
  • bSwitch to a different API key and continue at the same rate
  • cIgnore the header and treat 429 the same as a 500 server error
  • dImmediately retry the same request in a tight loop until it succeeds
Explanation:Retry-After tells the client how long to wait before the limit resets. Respecting it (with backoff) is the cooperative behavior rate limiting expects; ignoring it or retrying immediately just re-triggers the limit and can look like abusive traffic.
As Api SecurityDifficulty 1
What is "mass assignment" in the context of an API that accepts a JSON body to update a resource?
  • aThe server blindly binds every request field to the model, so clients can set fields they shouldn't control.✓
  • bSending the same request to multiple API endpoints at once
  • cA load balancer distributing requests across many backend instances, which is a separate infrastructure-layer routing concern unrelated to how any single instance parses a request body.
  • dEncrypting the request body with multiple keys for redundancy
Explanation:Mass assignment happens when a framework automatically maps all incoming JSON fields onto an object/model without an allowlist — so if the model has an is_admin or role field, a client can include it in the request body and the server will happily set it.
As Api SecurityDifficulty 2
PATCH /api/users/42
{ "name": "Ayşe", "role": "admin" }

The handler does user.update_from_json(request.body) where update_from_json sets every key it finds directly onto the user model, including role. What is the security problem?
  • aPATCH requests cannot contain a JSON body per the HTTP specification
  • bThe request is missing a Content-Type: application/json header, and without it most frameworks refuse to parse the body at all, so the handler never even runs.
  • cAny user editing their own profile can also set role to admin — privilege escalation via mass assignment.✓
  • dThe name field is not URL-encoded so it will corrupt the database
Explanation:Because update_from_json blindly binds every incoming field, role — a field the client should never control — gets written straight through, letting a normal user self-promote to admin. The fix is to bind only an explicit allowlist of editable fields (e.g. just name).
As Api SecurityDifficulty 2
Which approach best prevents mass assignment vulnerabilities in an API's update endpoint?
  • aRejecting any request body larger than 1 KB
  • bRequiring the client to send an API key in addition to a session cookie, which strengthens authentication but says nothing about which fields the authenticated caller is allowed to write.
  • cExplicitly listing which fields the endpoint may write, and ignoring/rejecting everything else (a DTO/allowlist).✓
  • dLogging every request body for later manual review
Explanation:The fix is structural: bind the request to a dedicated DTO/input object that only contains the fields meant to be user-editable, rather than binding directly onto the full domain model. Fields like role or balance simply never appear in that DTO, so no client input can reach them.

By specialization

AppSec 450Blue Team / Incident 450Cloud Security 450DevSecOps 450Offensive / Pentest 450

By seniority

Security JuniorSecurity MidSecurity Senior

Other fields

BackendFrontendFullstackDevOps / CloudAI EngineerDatabaseMobileQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 2850-question Security bank.

Start interview