API Security Study Portal

A: Broken Object Level Authorization is when an API endpoint receives an object id from the client, authenticates the caller, but never checks that the object actually belongs to or is permitted for that caller — so changing the id exposes other users' data. It's #1 because almost every API endpoint takes an object id, the checks are easy to forget per-endpoint, and the impact (mass data exposure) is severe.

A: BOLA is object-level ("can I access THIS specific object that isn't mine?"); BFLA (API5) is function-level ("can I invoke THIS operation/role I shouldn't have, like an admin endpoint?"). BOLA is wrong-object, BFLA is wrong-function.

A: Mass assignment (clients setting properties they shouldn't, like isAdmin) and excessive data exposure (returning more object properties than the client should see). Both are about authorizing access at the property level.

A: Binding the entire request body directly to a domain/ORM model, letting a client set sensitive fields (role, balance, verified). Prevent it with explicit allow-listed input DTOs that only contain the properties the operation legitimately accepts — never bind straight to the entity.

A: Returning full objects (including passwordHash, internal notes, other users' PII) and relying on the frontend to hide fields. Fix with output DTOs/serialization views that return only the fields the caller is entitled to, authorized by role where needed.

A: Most API breaches authenticate the caller correctly but fail the authorization check — at the object level (BOLA), function level (BFLA), or property level (BOPLA). Knowing who you are is not the same as checking what you're allowed to do to which resource.

A: Server-Side Request Forgery is when the server fetches a client-influenced URL, letting the attacker make the server request internal targets. Classic example: submitting http://169.254.169.254/latest/meta-data/... to steal cloud IAM credentials from the metadata service.

A: Allow-list schemes/hosts/ports, resolve the hostname and block private/loopback/link-local/metadata IP ranges, re-validate after redirects (DNS rebinding), disable redirects, segment the egress network away from internal services, and never return raw upstream responses.

A: No limits on CPU/memory/bandwidth/storage/cost a client can consume, enabling DoS and runaway bills. Mitigate with rate limiting/throttling, capped and validated pagination, request/upload size limits, query timeouts, and per-tenant quotas/spend limits on endpoints that trigger paid downstream calls.

A: API4 targets technical resource exhaustion (request volume/size). API6 targets abuse of legitimate business flows (scalping stock, fake-account creation, coupon farming) where each request is individually valid; the defense is anti-automation (CAPTCHA, device fingerprinting, behavioral detection) aimed at intent, not just raw rate.

A: Shadow APIs are undocumented/unknown endpoints or hosts not in your inventory; zombie APIs are deprecated-but-still-live versions that no longer get patched. Both expand attack surface. Fix with an authoritative, auto-generated inventory, current OpenAPI docs, and a formal deprecation/decommission process.

A: Trusting data from third-party/upstream APIs more than direct user input — passing their responses into queries/templates unvalidated, or following their redirects blindly. Treat the integration boundary as a trust boundary: validate/sanitize upstream data, use TLS with cert validation, don't follow upstream redirects, and apply timeouts and allow-lists.

A: API2 is about proving identity correctly (strong credentials, brute-force protection, proper JWT validation, token lifecycle). The authorization risks (API1/3/5) assume identity is known and ask whether the caller is allowed to do what they're attempting.

A: They're only defense-in-depth — they make ids harder to enumerate but don't enforce ownership. IDs leak (logs, referrers, shared links), and the real fix is a server-side ownership/permission check (or scoping queries to the authenticated user) on every object access.

A: Reflecting any Origin and allowing credentials lets a malicious website make authenticated cross-origin requests and read the responses. Lock CORS to a known allow-list of origins and avoid wildcard-with-credentials.