OWASP recently published their API Security top 10 list, and as the responses begin to mount, I wonder how often do we look past what is in front of us and task ourselves to view things differently. An introspection of the top 10, and it’s clear that authorization is the prevailing theme, requiring a recognition that APIs are distinctively unique, requiring their own identities.  Yet, faced with this truth, we still retreat to what we know, WAF and API gateways.

Modernization is the causality of the API boom, becoming increasingly more capable and demanding greater levels of trust. In Open Banking, their availability is mandated for third-party use. If we ignore these facts, we are not seeing APIs for what they are. Implementing unique identities, conditional authorization, data contextuality, and delegation capabilities starts the right path. Use of password-less authentication, abandoning passwords or tokens as proof of identity is a good start. There are nearly daily breaches, and they are often caused by the core concerns of the OWASP top 10.

Adoption hesitation is a valid concern as we look past not just the first iteration of APIs, but subsequent maintenance and change conformity. Avoiding hard coded anything requires externalization, but it must manifest as closely as possible to the unique identity/API for value and performance. From this, we obtain API independence with capabilities of fine grain authorization and begin to the recognize APIs for what they are, a vital conduit between your customers and that valuable data.

In re-examining the OWASP API Security Top 10 from an authorization perspective, these obstacles appear less daunting, and perhaps even attainable.

API 1 – Broken Level Authorization
Recommended solution: Authorization policies must contain object level attributes to enforce the specific data being allowed, denied, or the requiring step up authentication on a per identity basis.

API 2 – Broken Authentication
Recommended solution: Single-use authentication tokens for each transaction and not an entire session is highly effective, be cautious of latency if it is not occurring at the API level.

API 3 – Excessive Data Exposure
Recommended solution: Similar to API 1, apply explicit data object level fine grain authorization evaluated for each inbound and outbound request at the API.

API 4 — Lack of Resources & Rate Limiting
Recommended Solution: At a minimum provide load balancing and spike arrests at the Edge to protect backend services. Also employ scalable security with your scalable systems.

API 5 – Broken Function Level Authorization
Recommended solution: This vulnerability speaks to the need for distinct identities to ensure policies are applied per identity context and not at a group level with shared permissions.

API 6 – Mass Assignment
Recommended solution: Limitations of application edge enforcement techniques create substantial vulnerabilities as they only allow or deny all flows. Applying identity and object specific policies is an effective solution.

API 7 — Security Misconfiguration
Recommended solution: Separate code and security policies with an externalized authorization model and add consistent security policies to the entire CI/CD pipeline to avoid last minute changes and misconfigurations.

API 9 – Improper asset management
Recommended solution: Security by obscurity simply doesn’t work, nor any tricks to sufficiently “hide” endpoints from today’s browsers and extensions.  Implementing an identity driven access policy provides simple and effective remeditation.  Incorporating additional authorization conditions, such as data objects further extends protection.

API 10 – Insufficient Logging and Monitoring
Recommended solution: Effective and granular logging needs to originate from the service itself.  Luckily, a number of opensource tools are available for service tracing, but make sure they are capable of incorporating API authentication and authorization events for maximum value.