In 2023, it seems that every company is in the middle of an API transformation. Which makes sense, after all, because APIs have become the primary mode of communication for all connected services. And as a result, they are the primary attack vector for bad actors online. Teams need to up their API security, and quickly.
Once you start building a work program, however, you quickly find that there are many competing approaches to putting order and structure to your API estate. Some options include:
Richardson Maturity Model
The (Leonard) Richardson Maturity Model defines four levels of API maturity:
Level 0 – No APIs: At this level, there are no APIs in place, and all data exchange happens through a user interface or direct database access.
Level 1 – Resources: At this level, APIs are designed as basic resource endpoints. They are accessed over HTTP and can be thought of as simple web pages that provide information.
Level 2 – HTTP Verbs: At this level, APIs are designed to use HTTP verbs such as GET, POST, PUT, and DELETE to perform operations on resources.
Level 3 – Hypermedia Controls: At this level, APIs are designed to include hypermedia controls, which provide links to related resources and enable clients to discover and navigate the API dynamically.
The Richardson model is not very useful for making a plan to organize and secure an existing set of APIs for an enterprise, because it looks at API development and management as a linear pattern. But, most organizations have multiple teams and applications, with varied maturity and resourcing, which means that your API status will always contain elements at all four levels.
APIOps Cycles
The APIOps Cycles, created by Marjukka Niinioja, Jarkko Moilanen, and others, is a framework that focuses on the entire API lifecycle, from design to retirement. It’s focused on a product development and product management approach to API design and construction. It consists of eight stages:
Business First with API Canvas – This stage is focused on aligning business needs and customer journeys.
Mind the Developer Experience – In this stage, the focus is on making sure your APIs can be found, used, and supported.
Minimum Viable API Architecture – This stage is focused on making nonfunctional requirements as easy to accomplish as possible.
Build APIs – Here, the work is focused on designing simple-to-use interaction models, focusing on design styles and open standards.
API Audit – In this stage, APIs are compared against checklists of the previous stages as well as security.
Publish API – Here, the team makes the API available for the first time.
Monitor, Measure, and Analyze – This stage is focused on collecting metrics and KPIs to understand how your APIs are being used.
Learn and Improve – This final stage is about speeding up cycle time and improving quality of the APIs incrementally.
The APIOps Cycles framework emphasizes the importance of a holistic approach to API development and management, where each stage builds upon the previous one. It comes from lean/agile product development, and is focused on building APIs as products. This is very useful if you are mapping how mature your API development process is, but it doesn’t give you any information on the quality and maturity of the APIs themselves. The best development methodology can still create security and privacy vulnerabilities.
The API Security Maturity Model
Jacob Idesvog shared his API Security Maturity Model in 2019, as a response to trying to articulate the increased security risk from the proliferation of inadequate API construction and management. It has four phases:
Level 0: API Keys and Basic Authentication – If an API request presents an API key, then that key should be valid and should be trusted. It does not question the resources making the calls to the API at all.
Level 1: Token-Based Authentication – When an API call is accompanied with a token, the token can be used to authenticate the requestor before providing a response.
Level 2: Token-Based Authorization – In addition to an authentication, the API call is also expected to include a token that authorizes the requester to take certain actions (and to prevent them from taking other actions). This allows a lot of granularity in validating requests before delivering responses.
Level 3: Centralized Trust Using Claims – By introducing claims of veracity, we give the API the ability to independently assess the veracity of the authorization. Signed JSON Web Tokens (JWTs) are commonly used to present to share claims by using their in-built scopes capability. Third parties can leverage encrypted keys to validate payloads even after they are delivered.
Again, this model is useful when thinking through how to build and maintain protected API services. But, it falls short when we try to understand where risk lies within our existing environments. This model tells us what to do to make our APIs more secure, but it doesn’t tell us what APIs most need protecting, and to what extent.
A Different Approach
At Contxt, we know that most companies must move quickly into an API-first IT model. External products, internal applications, and backend services all use APIs, and they are in various states of maturity at any given time.
Several years ago, it was helpful to evaluate your APIs against these models to help you build APIs quickly and with high confidence.
But now that you are managing so many live API systems, attentions are turning toward identifying and remediating risky API construction, data transfer, and permissions.
We have shared our model for API maturity, that is focused on building a mature monitoring, detection and response capability for APIs that we must have, but can never fully control.
