The Invisible Attack Surface: The Era of APIs and Shadow APIs

API as the starting point of security — continuous visibility, assessment, and monitoring required Shadow APIs proliferating as AI adoption grows Attack paths must be identified and addressed through API graph analysis

In the previous article, we examined why Zero Trust cannot serve as a sufficient condition for security. Attacks are no longer evolving around bypassing trust — they are advancing by penetrating directly into internal systems through vulnerabilities. The natural question that follows: where do attackers get in? And are we truly aware of those entry points? The most critical answer to that question is: APIs.

Modern digital systems are no longer built from a single application or server. Most services are decomposed into dozens or even hundreds of microservices, all communicating via APIs. External users, too, don't access systems directly through web or mobile interfaces — they interact through API calls.

In today's systems, an API is not merely an interface — it is the functionality itself, and simultaneously, the attack surface. The problem is that this attack surface is expanding rapidly, at a pace that overwhelms an organization's capacity to manage it.

In DevOps and CI/CD environments, APIs are generated as fast as code is deployed. Every new feature introduces a new endpoint; temporary APIs are spun up during testing; unofficial interfaces are added for inter-system communication.

Not all of these APIs are centrally managed or documented. Those that fall outside governance are what we call Shadow APIs. This concept extends the well-known idea of Shadow IT — but the risk is far more direct. Where Shadow IT refers to unmanaged systems, Shadow APIs are open doors callable from the outside.

Real-World Incidents Proving the Danger of Shadow APIs

The list of attacks enabled by Shadow APIs is extensive. In 2021, Facebook suffered a breach in which the phone numbers and personal data of 533 million users across 106 countries were exposed. An internally operated unofficial API allowed large-scale data queries without adequate access controls, enabling the exfiltration of user identification data and phone number mappings. It was a textbook Shadow API incident — functionality absent from the official interface had been exposed externally through an unofficial channel.

In 2023, India's CoWIN vaccination platform experienced a breach affecting hundreds of millions of individuals. An API endpoint with excessive privileges exposed to the outside world was identified as a primary cause. Data that was inaccessible through the official user interface was bulk-harvested by calling the API directly.

The MOVEit file transfer vulnerability that caused massive damage that same year can also be reinterpreted through this lens. Many of the affected organizations believed they were using MOVEit solely for internal file transfers — yet externally accessible API endpoints were in fact exposed. That invisible exposure became the attacker's point of entry.

In every one of these cases, the attack entry point was not a system under formal management, but an API that the organization had either failed to recognize or had allowed to fall outside its governance framework.

The dangers of Shadow APIs manifest across three dimensions.

First, lack of visibility. Organizations typically maintain reasonably accurate inventories of their servers and network equipment. APIs are another matter. Legacy services, test environments, outsourced development artifacts, and informally created internal APIs are prone to falling off the management register. When that happens, they are excluded from security assessments — and any vulnerabilities they carry may go undetected and unaddressed for extended periods.

Second, imbalance in security controls. Formally operated APIs are subject to security controls such as authentication, authorization, rate limiting, and input validation. Shadow APIs, by contrast, often receive none of these protections — or only a bare minimum. The pattern of omitting authentication because an API is "internal," or granting excessive privileges without justification, is one that appears repeatedly in real-world attacks — and has already resulted in multiple confirmed incidents.

Third, structural interconnectivity. APIs do not exist in isolation. One API call leads to another; data flows and authorization flows are intricately intertwined. A single vulnerable API is therefore not merely a point problem — it becomes a launchpad for lateral movement across the entire system. Attackers exploit this interconnected architecture to escalate privileges incrementally and ultimately reach core assets.

For this reason, modern security is increasingly moving away from examining individual APIs or individual vulnerabilities in isolation. Instead, the focus is shifting toward constructing attack graphs — representations that capture the full structure of multiple vulnerabilities and assets in aggregate. In these graphs, each asset and vulnerability is a node, and the access paths and dependency relationships between them are edges.

Graph Neural Networks (GNNs) operate on top of these attack graphs to estimate and predict the paths most likely to lead to actual penetration, as well as the pivot nodes most valuable to an attacker. Rather than evaluating the severity of a single vulnerability in isolation, the model considers how that vulnerability connects to other nodes — learning which paths lead inside. The high-risk paths and nodes identified through this process are only realized as a fully actionable defense strategy when combined with the continuous vulnerability management model and the automated response frameworks based on Zero Trust and SDN architectures, which will be covered in Part 3.

More recently, generative AI and security-specialized models are surfacing API vulnerabilities that previously went undetected, while scanners such as Nuclei and OpenVAS automate the discovery of both public and shadow APIs — making these attack surfaces and attack graphs increasingly visible.

How AI Expands the Attack Surface

These challenges are being compounded by the rapid diffusion of AI technology. Generative AI and agent-based systems generate enormous volumes of internal API calls. A single user request may trigger a cascade of calls to multiple internal services and external APIs — in the process, new API endpoints can be dynamically created or exposed. Meanwhile, developers leveraging LLMs to rapidly build and ship services are increasingly deploying APIs that have not undergone adequate security validation.

The more significant shift, however, is happening on the offensive side. In the past, attackers needed considerable time and effort to reverse-engineer a system's architecture. Today, AI can be used to infer API structure, probe endpoints, and automatically analyze input patterns. With access to only a portion of a public API, it is now possible to reconstruct the overall service architecture — or to discover hidden parameters based on response patterns. Attackers are no longer hunting for individual vulnerabilities; they are analyzing the entire API graph and computing optimal attack paths.

Redefining the Asset

This brings us to a critical conceptual shift. For a long time, we have defined assets as physical or logical infrastructure — servers, databases, network equipment. In today's environment, the effective unit of an asset is the API. Data is exposed through APIs. Functionality is executed through APIs. Privileges are exercised through API calls.

As the Facebook and CoWIN incidents illustrate, what gets compromised is not the server — it's the API. To leave APIs unmanaged is, in effect, to leave your actual assets unmanaged. From this perspective, it also becomes clear why traditional vulnerability management frameworks fall short. Conventional vulnerability management is built on an asset inventory model: identify the systems in scope, periodically assess vulnerabilities against those systems, and patch what is found.

But this model rests on a foundational assumption — that assets are static. In environments where APIs are continuously created and retired, that assumption no longer holds. Periodic assessment also introduces inherent temporal gaps. New APIs created between assessment cycles, and vulnerabilities that emerge in the interim, remain exposed. In an AI-driven attack environment, those gaps translate directly into attack opportunities. Periodic scanning is, by structural design, always a reactive response.

The core question in modern security is no longer "does a vulnerability exist?" — it is "do we know which APIs carry vulnerabilities?" And few organizations can answer that question with confidence. Security strategy must therefore pivot simultaneously in two directions. First, real-time visibility — the ability to identify and track every API as it appears. This means going beyond documentation to automatically detecting APIs that actually exist, based on network traffic and service call analysis. Second, continuous exposure assessment — a system that evaluates the vulnerability exposure of each API on an ongoing basis and dynamically updates risk scores.

Ultimately, APIs are no longer merely the output of development — they are the starting point of security. And Shadow APIs are no longer an edge case to be handled as an exception — they must be assumed to exist as a baseline reality.

The next article will address how, in this environment, vulnerabilities can be prioritized, the likelihood of exploitation predicted, and elimination made continuous. In particular, we will examine in concrete terms why a new approach — one that moves beyond simple score-based evaluation to incorporate weaponization potential and structural characteristics — is now essential.

---

원문 보기

데이터넷