By: Mayur Upadhyaya and Jamie Beckland
Every API call has context around it.
- Who is making the API call?
- What data are they requesting or attempting to post?
- Is that data public or private?
- Do we need to check with anyone else before permitting the request?
- Does the data transfer have any legal or ethical considerations or constraints?
Our goal should be to provide the right response, in the right context, every time.
But, for the past decade, APIs have moved at the speed of business. APIs have grown so quickly because they have proven their value in creating flexibility and functionality. The cost, however, has been with inconsistent security, privacy, and performance rigor.
That’s why there have been so many data issues, breaches, and leaky APIs recently. Bad actors know that the APIs are the weak link in protecting your customers’ and your business’ data assets.
Our approach to API context maturity comes from understanding that you are building the plane while you fly it. You need to move quickly, and enable teams to deliver business objectives. One approach is to slow teams down by asking them to be experts in security and privacy (in addition to all of the other functions that they need to be experts in).
We think you get better outcomes faster when you ensure that there are adequate guardrails, so teams can’t make egregious mistakes, while maintaining velocity.
Then, incrementally, we can raise the guardrails to enforce higher standards for use cases where more protection is necessary.
The API Context Maturity Model breaks down building and maintaining APIs with an increasingly sophisticated understanding of the context surrounding the API call.
Level 0 - Open, public API calls. These calls require no information from the requester before delivering a response. This may be totally appropriate for many (or most!) API calls. An API call that delivers weather for a location, or the cost of a flight, may not need any special protections, and Level 0 works well. It is fast and efficient, and ensures that the barrier to deploy and maintain these services is as low as possible. However, if an API call contains personal or sensitive data, or if it requires authentication, Level 0 is not appropriate.
Level 1 - Authenticated API calls. These calls have an understanding of who the requester is, and can provide information specific to that requester. There are lots of reasons that an API call should be authenticated. Perhaps a customer wants to know information about their account. Or you need to monitor the usage of the API call, so you need to understand how much each user is calling the service. Or there is proprietary pricing and inventory information that you only want to expose to certain employees and partners. Regardless of the reason, any API that needs to be authenticated should have validation of authentication every time it is delivered. There are many ways to authenticate an API call, and different levels of authentication should apply to different APIs.
Level 2 - Authorized API calls. These calls have specific permissions and requester expectations attached to them. For example, maybe you offer different bulk pricing discounts to different partners, based on the level of commercial relationship. You want to make sure that pricing information is not shared with every user and system from the partner, but customize the response based on the authorization scope. Another example is when you have different services calling the same API endpoint, and want to return different information. If your get_customers endpoint is used by your internal analytics tool, you may want to share birthdate, mailing address, and other personal information. But, when your advertising partners call that same endpoint, you need to reduce the scope of the payload to avoid sharing PII.
Level 3 - Purpose and use defined. These calls rely on an understanding of why and how the data in the payload will be used. Perhaps the subject of the data request needs to consent for the requester to have the data, or to use the data in certain ways. You may need to collect consent from a patient to share their health data with their doctor or other provider. Or, with proper customer consent, you actually can share PII with advertisers.
Level 4 - Open standards compliant. These calls are critical to core business operations, and as such, they need to conform to rigorous public standards. In many markets, standards that have been developed and hardened in public working groups are now being adopted as regulatory requirements for operations. Regulators in finance, health, and other areas may want to periodically review API calls to ensure compliance.
The API Context Maturity Model requires an understanding of each individual API call; and also of the specific circumstances of that call. As APIs move through the levels in the model, the complexity to and assurance does not go up linearly. It is much more complex to interpret changing regulations than simple authentication.
But, the framework provides a glidepath for Enterprises to incrementally improve their risk posture, and demonstrate conformance quickly.
Implementing this maturity model becomes dramatically easier when you have an accurate understanding of your existing APIs, because the highest risk becomes clear quickly.
Top comments (0)