APIs as Part of the Supply Chain: Why Interface Security Becomes a Matter of Evidence
NIS2 pulls the supply chain into the risk picture, and APIs are its quiet connectors. Why authorization flaws are the biggest API weakness, and why you can only secure what is cleanly documented.
Software is rarely a monolith today. Modules, partner services and tenants talk to each other through interfaces, and these APIs are the quiet connectors of the supply chain. NIS2 explicitly requires supply chain security as part of the risk picture. That moves a question long treated as purely technical to the foreground: how secure, and how auditable, are your own interfaces?
The interface is the attack surface
The most common API weaknesses are not exotic exploits but authorization flaws. In the OWASP API Security Top 10, Broken Object Level Authorization sits in first place: an API hands out data without properly checking whether the requesting account is allowed to see it at all. A changed object ID in the request is then enough to retrieve someone else’s records. Three control points decide robustness in practice:
- Per-object authorization: Every request checks whether the caller may see or change this specific object, not merely whether they are logged in.
- Authentication: Tokens are short-lived, bound and revocable, rather than long-lived general-purpose keys.
- Throttling: Rate limiting and quotas keep an interface from becoming a data-exfiltration point or a load vector.
What you do not document, you cannot secure
Many incidents trace back not to known interfaces but to forgotten ones: shadow APIs that never reached the inventory, and zombie APIs left open after a version change. Without a complete, current inventory, any defence stays patchy. A well-maintained OpenAPI description is more than developer convenience here: it is the contract against which permissions, versions and expected behaviour can be checked at all. A dedicated developer portal that holds these descriptions in a versioned, multi-tenant way turns scattered knowledge into a traceable register.
Security as a demonstrable property
When the regulator asks, it is not enough to say the APIs are secured. What is required is evidence: which interfaces exist, in which version, with which permissions, and who retrieved what and when. Versioning, access logs and a maintained interface register turn security from an assertion into a property you can prove. This is the same logic NIS2 applies elsewhere to monitoring and reporting, only applied to the connectors between systems.
A supply chain is only as trustworthy as its interfaces. And an interface that no one fully knows can be neither secured nor proven.