API Security · beginner · ~10 min
Explain why APIs differ from web UIs as a testing target and how to enumerate them.
APIs are the backend's direct attack surface: no UI to guide you, objects exposed by ID, frequent over-trust of the client, and version sprawl. They have their own OWASP API Top 10 (BOLA, BFLA, mass assignment, resource consumption). Enumerate via client traffic, Swagger/Postman, and fuzzing.
Most data and logic now live behind APIs, where authorization bugs dominate and there's no UI to bound what you try. Enumerating the full endpoint map is the prerequisite for testing each one's access control.
No UI bound. Endpoints must be discovered, not clicked. Object-by-ID. Authorization (BOLA/BFLA) is the dominant bug class. Client over-trust. Hand-crafted requests under-checked. Version sprawl. Old endpoints, weaker checks. Enumeration. Client JS/traffic, Swagger/OpenAPI, Postman, fuzzing.
Modern apps are mostly APIs with a thin client on top. The API is where the real logic — and the real attack surface — lives.
/v1/, /v2/, deprecated-but-live endpoints with weaker checks.APIs have their own risk list, distinct from the web Top 10. The standouts (covered next): Broken Object Level Authorization (BOLA), Broken Function Level Authorization (BFLA), mass assignment, and unrestricted resource consumption (rate limiting).
APIs expose the backend directly, with no UI to constrain testing and objects reachable by ID — so authorization flaws lead the OWASP API Top 10. The first job is enumerating every endpoint, parameter, and object to test.