OWASP Top 10 has been the bible of web application security for two decades. The question a Pivot Point Security podcast featuring Resurface Labs CTO Rob Dickinson asks is whether the framework is still valid in an API-centric world where there is no trusted client and the application is code calling code across the internet.
The short answer is that OWASP is still the right starting point, but the architecture has changed underneath it, and the attack surface has grown in ways the framework was not designed to address.
Key facts
- API-centric applications run as microservices that are themselves small web servers.
- Traditional web app attack vectors (injection, protocol manipulation) apply to API microservices, plus new API-level attacks.
- The SDLC now has to extend into production for meaningful feedback.
- API-centric development reduces visibility, because only the development organisation can see what is exposed.
- The shift to APIs is the opposite of the long-standing security advice to reduce attack surface.
What the conversation actually argues
Dickinson's framing is sharp. APIs inherit every security problem that web-based systems have always had, and then add new ones. The microservices that implement APIs are small web servers, so every traditional web attack applies to them. On top of that, the API layer introduces its own attack class, including user impersonation and rights escalation.
The example he gives is GraphQL, which can be attacked through method injection, broken validation, and resource exhaustion by design. These are not exotic attacks. They are the same old problems applied to a new architecture that the old frameworks were not written for.
The other argument is about the SDLC. In an API-centric world, the SDLC does not stop at production. It has to extend into production, with feedback loops that feed real behaviour back into the design process. Without that loop, the developers are flying blind about what their APIs are actually doing.
Our analysis
The API-centric shift is the most important architectural change in application security in a decade, and most application security programmes have not caught up. The frameworks are still organised around web applications. The testing tools still assume a trusted client. The secure code review process still assumes a human can read the entire codebase.
None of those assumptions hold for a microservices-based API architecture. The codebase is distributed across many services, owned by different teams, deployed independently, and called in ways that the developers did not anticipate. The OWASP Top 10 is still a useful teaching tool, and the ASVS is still a useful verification standard, but the operational reality has outgrown them.
The most uncomfortable point in the conversation is the one about visibility. In a web-centric world, anyone in the company could open a browser, look at the site, and have a sense of what was exposed. In an API-centric world, only the development team has that visibility, and even they do not always know what is in production. That is a structural change in the attack surface, and it is one that most security programmes have not yet addressed.
Who should care
| Audience | Why it matters |
|---|---|
| Security leads managing migrated portfolios | Your existing OWASP review may not cover the distributed attack surface you now have in production |
| API-first developers | OWASP Top 10 is necessary but not sufficient; you need runtime feedback loops the framework does not prescribe |
| Compliance teams using ASVS as a checklist | Static verification does not capture production behaviour or the visibility gap in a distributed architecture |
| CISOs reviewing programme coverage | Your pen test scope may be narrower than your actual exposure; ask whether your programme accounts for structural visibility loss |
What to watch next
Three things. First, the OWASP API Security Top 10 is becoming more established, and security programmes that have not adopted it as a baseline are going to look outdated. Second, runtime application security testing is going to become the standard, not the exception, for API-centric applications. Third, service mesh with consistent policy enforcement and API gateway logging are the practical starting points for closing the visibility gap.
The bottom line: OWASP is the right starting point, but the architecture has changed, and the security programme has to change with it.
Key takeaways
- APIs inherit all the web app attack vectors and add new ones, so OWASP Top 10 is necessary but not sufficient.
- Microservices are small web servers, which means every traditional web attack applies to them.
- The SDLC has to extend into production for meaningful feedback in an API-centric world.
- Visibility is structurally worse in an API-centric architecture, and most security programmes have not addressed it.
- Service mesh, API gateway logging, runtime testing, and a production-to-design feedback loop are the new baseline.
Frequently asked questions
Is OWASP Top 10 still valid for API security?
It is a useful starting point but does not cover API-specific attack classes like broken object level authorisation or excessive data exposure.
What new attacks do APIs introduce?
User impersonation, rights escalation, method injection, and resource exhaustion, on top of all the traditional web app attacks.
Why is visibility worse in an API-centric architecture?
Because only the development team can see the exposed surface, and even they do not always have a complete inventory of what is in production.
Should the SDLC extend into production?
Yes. The feedback loop from production behaviour back into design is the only way to catch issues that testing missed.
What is the first step to secure an API-centric application?
A complete inventory of the APIs in production, because you cannot protect what you cannot see.