API // Contracts, Auth and Object-Level Abuse

API Security

API security deserves its own domain because the attack logic is different from browser-first web testing. APIs expose object models, trust assumptions and business actions directly. That makes authorization mistakes, data-shaping flaws and automation abuse more scalable and easier to hide behind perfectly normal client behaviour.

domain huboperator referencepublic sources

Domain overview

This domain covers REST, GraphQL and gRPC-adjacent thinking, JWT and token handling, OAuth/OIDC, rate controls, BOLA/BFLA, mass assignment, schema abuse, discovery workflows and API fuzzing. The job is to model what the backend thinks the caller is allowed to do, then prove where that model breaks under alternate identifiers, roles, claims, objects, content types or request cadence.

How to approach this surface

  • Map the object model, not just the endpoints. Most serious API flaws live in relationships between users, tenants, roles and objects.
  • Test identity and authorization separately. A valid token only proves presence, not correct scope or object-level access.
  • Watch how the backend handles extra fields, nested objects, alternate content types and version drift. Mass assignment and schema confusion love these edges.
  • GraphQL deserves dedicated treatment: introspection, batching, field-level auth, resolver trust and query-cost abuse often create unique failure modes.
  • Rate limiting is not just anti-abuse hygiene. It shapes enumeration cost, token replay risk and the feasibility of business-logic automation.

Related certification and framework context

Curated public references

Brief index

brief

REST and HTTP Assumptions

Endpoint discovery, object mapping, verbs, content types and error handling as an attack surface.

field notepublic links