API Security

APIs expose the real “create/update/delete” actions of an application. Even if the UI is strict, Someone can call APIs directly. So APIs must enforce authorization and validation server-side for every request.

In the wild: API credential incidents are boring and brutal — one leaked token + missing scoping/rotation becomes a full environment compromise.

60-second interview answer: “I start with authorization (BOLA/BFLA). Then I validate authentication and token handling (JWT/OAuth). Next I test schema validation and mass assignment. Finally I assess abuse controls like rate limits, logging, and monitoring. Fixes should be centralized authorization policies plus strong tests.”

Mental model (attacker mindset)

Who is calling? (identity)
What action are they calling? (function)
Which object is affected? (object)
Are they allowed for this object and action? (policy)
Is the request valid and safe? (schema/validation)
Can it be abused at scale? (rate limits, monitoring)

API testing methodology (repeatable)

1) Build an Authorization Matrix

List roles: anonymous, user, admin, support, partner, service accounts.
List objects: users, orders, invoices, tickets, documents, wallets.
For each endpoint define: role → allowed actions → object constraints.

2) Capture “golden requests”

Record clean requests for the key actions (create/read/update/delete, approve/refund/export).
Replay across users/roles and compare response + side effects.

3) Validate schema and state

Check types, required fields, enums, max lengths, nested object limits.
Confirm server rejects unknown fields (prevents mass assignment).
Verify workflow/state transitions (e.g., can you mark “paid” without paying?).

High-yield API vulnerabilities

Vulnerability	Explain simply	How to test (interview-safe)	How to fix
BOLA (Broken Object Level Authorization)	Change an ID and you access someone else’s object.	Swap IDs across accounts; check nested IDs; verify unauthorized read/write.	Enforce ownership checks server-side on every request; deny-by-default; central policies + tests.
BFLA (Broken Function Level Authorization)	Normal user calls admin-only functions.	Call privileged endpoints with low-priv tokens; test method switching and hidden endpoints.	Centralize authZ; consistent role checks; separate admin surfaces; least privilege.
Mass Assignment	API accepts extra fields and updates sensitive attributes.	Add “shouldn’t change” fields (role, isAdmin, price, status) and check persistence.	Allow-list DTOs; reject unknown fields; server-controlled fields only.
Excessive Data Exposure	API returns more data than needed (PII/internal flags).	Inspect responses for hidden PII, internal IDs, admin flags, tokens, debug fields.	Response shaping; separate internal/external DTOs; minimize fields.
Rate-limit / abuse gaps	Attackers brute force, enumerate, or spam operations.	Check throttling on login, OTP, password reset, search, exports, payments.	Per user/IP/device throttles; progressive delays; detection + alerts; safe errors.

Remember: Real-world API breaches are often authorization failures (BOLA/BFLA) more than “fancy crypto”.

JWT basics (deep but clean)

JWT is a signed token containing claims about the user and permissions.

Must validate: signature, exp, iss, aud, and expected algorithm.
Common failures: skipping claim validation, trusting client-provided roles, weak key handling.
Good practice: short-lived access tokens, refresh rotation, revoke on sensitive events.

OAuth2 basics (interview framing)

Plain: OAuth lets an app access an API on a user’s behalf with scoped permissions.

Deep: emphasize scopes, consent, token lifetime, correct redirect handling, and server-side scope enforcement.

API checklist (quick revision)

✅ AuthZ matrix (BOLA/BFLA)
✅ Strict token validation (JWT claims, rotation)
✅ Schema validation + allow-list DTOs (stop mass assignment)
✅ Rate limiting + monitoring for sensitive endpoints
✅ Minimize response data (no excessive exposure)
✅ Strong audit logs (“who did what to which object”)

Safety note: for interview prep and