// appsec · guide

API Security Testing: The Attack Surface Everyone Forgets

Mobile apps, single-page frontends and partner integrations often rely on APIs. Reviewing only visible pages can miss backend operations, object ownership and data that the interface never displays.

Why APIs are different

APIs expose operations and data to clients. Testers need an inventory of in-scope endpoints, representative roles and tenants, and an understanding of high-value workflows. Neither a browser-only crawl nor the existence of an OpenAPI schema establishes complete coverage.

Risks to investigate

• Broken object-level authorisation (BOLA) — change an ID in the request, get someone else's data. This can expose records across users or tenants when server-side checks are missing.
• Broken function-level authorisation — call an admin endpoint as a normal user because the UI just hid the button.
• Excessive data exposure — the API returns full objects and trusts the client to hide fields. It doesn't.
• Unrestricted resource consumption — missing bounds on request size, pagination or expensive operations can enable service abuse.

How proper API testing works

Use authorised test identities across roles and tenants, then replay and vary requests within the agreed scope. Investigate object, property and function boundaries as well as sensitive business flows. Record tested routes, exclusions and evidence; do not infer coverage from the name of a test. The OWASP API Security project is a useful baseline.