Managing API Sprawl: The Growing Risk Of Shadow APIs & How To Mitigate It

Uploaded on 2024-11-18 in TECHNOLOGY--Resilience, FREE TO VIEW, BUSINESS-Services-IT & Telecoms

As organisations continue to migrate towards microservice-based architectures, implement real-time data strategies and shift towards API-first approaches, managing and governing APIs often becomes increasingly complex.

The more APIs you have, the more APIs you need to secure, manage and govern. It doesn’t take long to reach the land of “API sprawl,” where there are hundreds, or even thousands, of new APIs that aren’t properly accounted for.

While this all seems simple and predictable, it’s something that many organisations still struggle with. These struggles typically take the form of “shadow APIs” - undiscovered and unmanaged legacy APIs that are often still running in production. These APIs present serious risks for any business.

Increasing Vulnerability To API Security Breaches

The lack of visibility into a rapidly growing API landscape creates a breeding ground for security vulnerabilities. Shadow APIs, often unmonitored or poorly maintained, become prime targets for attackers who exploit improper authentication logic or weak encryption standards. Kong research highlights this risk, with the number of annual attacks forecast to grow 548% by 2030, for a total of 42,000 API attacks in the U.S. alone.

Because these APIs are often not tracked or monitored, they can inadvertently expose sensitive data, such as customer personally identifiable information (PII), financial records or proprietary business information. For example, a legacy API developed for a now-defunct service may still have access to sensitive databases, unintentionally exposing data to anyone who knows how to call it. What’s most concerning is that these data leaks often occur silently, without anyone in the organisation noticing until it’s too late.

Improving API Governance With Service Catalogues

The inability to fully account for all APIs means that organisations struggle to comply with industry regulations. APIs that process sensitive data may fall outside of mandated compliance checks, such as GDPR or HIPAA audits, simply because they aren’t catalogued as part of the organisation’s official API inventory. This lack of oversight can result in costly regulatory fines, not to mention the potential damage to customer trust.

Just like a library catalogue helps patrons find materials, a service catalogue acts as a centralised system of record for an organisation’s services and APIs. The service catalogue is the discovery and visibility mechanism for all of your APIs and services. In other words, it’s the bane of API sprawl and shadow APIs. Let’s break it down further.

One of the most powerful features of a service catalogue is its discovery engine, which dynamically updates the catalogue as new services are deployed and inactive ones are decommissioned. The discovery engine allows the service catalogue to retain both its accuracy and reliability as a source of truth with zero manual intervention.

It is important to note, however, that not all service catalogues are created equal.

Certain catalogues whose discovery engines do not deeply integrate with critical infrastructure (like API gateways and service meshes) typically need to be populated and maintained by hand. These manual processes are highly prone to error and result in outdated catalogues almost immediately.

In other words, if your service catalogue can’t auto-populate, it undermines the entire purpose of adopting such a solution. You may as well try to manage, measure and govern every API and service manually in an Excel sheet. This is untenable for an organisation with a massive service footprint.

An automated service catalogue that is built to deeply integrate with various infrastructural applications offers complete visibility into an organisation’s north-south and east-west API traffic. This allows the catalogue to display analytics about the service (such as request count, error rate and latency) that reflect its dynamic real-world usage, rather than static and outdated data.

Organisations can no longer afford to leave critical customer data, PII and authorisation credentials just “floating” out there, unseen, in production. Hope cannot be your API security strategy.

Miko Bautista is Product Manager at Kong Inc.

Image:

You Might Also Read:

Five Reasons Your Organization Needs API Security Testing:

If you like this website and use the comprehensive 6,500-plus service supplier Directory, you can get unrestricted access, including the exclusive in-depth Directors Report series, by signing up for a Premium Subscription.