How to Streamline API Development with Consistent API Controls Across Teams

This post is part of a series on becoming a secure API-first company. For a deeper dive, check out the eBook Leading Digital Transformation: Best Practices for Becoming a Secure API-First Company.

The growth of APIs isn't just rapid — it's a seismic shift. Industry insiders say they plan to introduce more APIs in the next five years than all the APIs they've created up until today. And this impending surge will place a serious burden on mission-critical API infrastructure.

How can organizations navigate this influx while ensuring robust security measures are in place?

In this post, we'll look at the API development process, why adopting consistent API controls across teams is essential, and how to develop API infrastructure that minimizes inconsistencies in API policy creation and enforcement.

What are API access controls?

API access controls are a suite of security measures for regulating interactions between authorized users, applications, or systems and an API. These controls encompass a variety of mechanisms such as authentication, authorization, rate limiting, IP whitelisting and blacklisting, protocols for encrypting data in transit, SSO (single sign-on), and API keys — all of which are essentially used to control access to API functionalities and data.

Robust and consistent API access controls help uphold data privacy, integrity, and availability while allowing for the necessary interaction between users, applications, and APIs.

Standard API development process

Understanding the API development process is pivotal to implementing the right number of robust and consistent API access controls that will mitigate the risk of introducing fragmentation and backdoors into the way APIs are managed.

Developers creating APIs typically follow these steps:

1. Design

At the outset, APIs are meticulously designed. Teams gain a comprehensive understanding of the requirements, collaborating with product managers. This process involves figuring out things like what the API should achieve, which endpoints are required, and what responses will entail.

During this stage, it's important that the API is designed with extensibility in mind as API functionality will need to evolve and change over time. Thinking about extensibility early on can help reduce the pain of migrating APIs to a different version down the road.

2. Implementation

Once the design is agreed upon, coding begins to actualize the API’s intended functionality.

An implementation language, framework, and dependencies are selected. It's important in this stage that the team also implements the right testing strategy to continuously test that the API implementation they're building is conforming to the expected behavior with unit and integration tests.

3. API management

At this stage of the API development cycle, the API has little to no management capabilities

This phase shifts focus to protecting the API, implementing security measures, and adopting tools for efficient traffic and access management. Questions to be considered here include figuring out how to invoice users to consume the API, how to create (and revoke) credentials, and how to monitor API traffic.

4. Operation

This final step is about the API operational lifecycle that a team will need to continuously implement throughout the journey of their own API in an agile way.

Now the API is up and running. But at some point, the team will want to introduce changes (like version releases or feature-flagged beta versions). Techniques such as blue/green deployments and canary releases allow smooth transitions without downtime. It will also be important to implement traffic mirroring capabilities to test the staging environment with a subset of mirrored production requests for debugging and other operational changes.

API management vs API operational lifecycle

Often organizations confuseAPI management with the API operational lifecycle.

• API management is what the organization and the platform team are responsible for.
• API operational lifecycle is what developers need to be agile and ship fast.

Often, organizations give freedom to the teams to implement both use cases, and by doing so they're distributing more API infrastructure ownership than they should to the application teams, which aren't prepared to take full responsibility for both areas (though they sometimes accept it).

Streamlined API development and management

Without streamlining API development and offering centralized API management that can cater to the requirements of every API in the organization, teams inadvertently integrate management capabilities into their development processes, creating ad-hoc solutions for each API. The platform team has no visibility and control over these.

Developers (as builders) often desire to build API controls within their applications. But this runs against the need for organizational control over the API security of the underlying infrastructure.

The absence of standardization on a consistent API platform and infrastructure can lead to many potential issues, including lost productivity and fragmented controls.

• Lost productivity — When developers divert from their core competency, productivity takes a hit. Developers should be building products and APIs, not underlying API infrastructure. Developers can also underestimate the complexity involved in building, maintaining, and updating ad-hoc API infrastructure over time.
• Fragmented controls — When APIs are repeatedly built with inconsistent controls, it creates silos that obscure secure management. With a lack of oversight, the organization is unable to assess risk profiles across APIs, and potential security vulnerabilities surface due to fragmentation, which creates a broad error surface that a malicious attacker can exploit (since each implementation of the same capability may be built slightly differently).
• Maintenance challenges — Ad-hoc controls require continuous upkeep, undermining reliability and productivity. The duplicated effort is wasteful and results in a convoluted security landscape.

Consistent API controls made possible by API management

The right API management platform addresses the above challenges — and comes with a host of other benefits. An API management platform can provide a unified control plane for API security, management, and operation.

Without a modern API platform, the growing number of APIs and microservices also leads to the growth of duplication and fragmentation. This is also true when adopting multiple API platforms from different vendors.

The inability to have one control plane to assess and manage the security profile under a single glass pane creates a void ready to be exploited. It also creates a conflict with the security team, which can't chase teams down to validate the security of their implementations — some of which they may not even know about as they're essentially "shadow IT."

The API controls typically applied on a modern API infrastructure are:

• Security —Network layer security (firewall and DDOS protection, zero-trust security), application security (AuthN/Z, credentials management) traffic security (anomaly detection, backdoor testing)
• Traffic management — Rate limiting, tiering, ACL, blue/green deployments, canary releases, API traffic mirroring, and more
• Analytics and logging — API monitoring, usage analytics, access logs, and more
• Onboarding — Registering for an API, being able to manage different environments (testing and production, for example)
• Portal and collections — Developer portal for API documentation, client libraries, request collections to more easily debug and use the APIs

From a security standpoint, the importance of the API development phase is to (first) help to create a comprehensive, well-documented OpenAPI specification that satisfies API usage requirements and (second) guarantee proper unit and integration testing is created to ensure that the API isn't leaking more data than it should on every API request.

The OpenAPI specification can then be used during the API management phase to validate that the person consuming (or using) the API can only make requests to endpoints that have been explicitly defined. This disrupts the ability of a potential attacker to identify backdoors in the API by making requests to endpoints that weren't supposed to be exposed.

Because we know that APIs are mission-critical infrastructure, it's no longer acceptable to create siloed API infrastructure without clear, defined ownership and visibility into the quality of the underlying controls implemented. We want to ensure that the security team has properly assessed and validated that the infrastructure in place is in compliance with their requirements.

In organizations where pockets of API infrastructure are entirely managed by the application teams, there's no practical way for any leader in the organization to accurately assess the risks and take action.

Conclusion

Ultimately, as the rising number of cyber-attacks has shown us, API security is the responsibility of the platform team and the organization's leadership.

There's a tendency to think there's an ideal time to implement these changes that will present itself at some to-be-determined point in the future. But the rising number of attacks shows us the time is now to own API infrastructure.

Take control of your API security with Kong

Kong’s comprehensive API management and service mesh platform, complemented by Kong Insomnia — which supports collaborative API design based on the OpenAPI specification — empowers organizations to develop, test, and manage APIs seamlessly.

Ready to enable consistent controls, unleash productivity, and strengthen your API security? Get a free trial of Kong Konnect today.