DEV Community

kozhevniko
kozhevniko

Posted on

API Security: The Attack Surface That Grows Without a Firewall

#apisecurity #owasp #authorization

API Security: The Attack Surface That Grows Without a Firewall

Every new application feature tends to arrive as an API endpoint. Mobile clients, partner integrations, and internal automation all consume the same interfaces, and those interfaces are usually authenticated by tokens rather than protected by network position. The result is an attack surface that expands with the product roadmap and rarely shrinks.

Why APIs are different

Traditional web application security assumed a browser, a session cookie, and a user who could be challenged. APIs assume a machine client with a long-lived token and no interactive challenge. Business logic that would be tedious to abuse through a user interface can be automated against an API at scale.

Two failure patterns dominate. The first is broken object-level authorisation, where an endpoint accepts an identifier and returns data without verifying that the caller is entitled to it. The second is excessive data exposure, where an endpoint returns more fields than the client needs, leaking internal attributes.

The OWASP API Security Top 10 documents both patterns and has tracked them consistently across editions.

What the incident record shows

API weaknesses have featured in several large-scale incidents. The 2021 Peloton API issue, in which an unauthenticated endpoint returned user profile data, is a well-documented example of missing authorisation on a data-returning endpoint. More recently, breaches at identity and data providers have involved token theft and API access rather than exploitation of a memory-safety flaw.

The pattern is consistent: the API is doing exactly what it was programmed to do, and the authorisation check is missing.

Practical controls

  • Enumerate APIs and treat the inventory as a living asset list, including internal and partner-facing endpoints.
  • Enforce object-level authorisation on every request, and test it with automated checks that attempt to access other users' identifiers.
  • Return the minimum field set and validate responses against a schema in testing.
  • Rate-limit by identity and by endpoint, and alert on enumeration patterns rather than only on volume.
  • Rotate tokens, scope them narrowly, and monitor for use from unexpected networks.

Conclusion

APIs are where application logic meets automation, which makes authorisation errors both easy to introduce and easy to exploit at scale. Treating the API inventory as a first-class asset, and testing authorisation as rigorously as authentication, addresses the failure modes that appear most often in practice.

References

Top comments (0)