Discovering your APIs – How to achieve a complete API Inventory

API usage and traffic continues to grow thanks to the massive amount of SaaS and other web-based services that power our modern economies. However, as businesses become more distributed the landscape of their API estate and microservices has become increasingly complex. These vast and potentially ungoverned API landscapes present attractive targets for attackers and challenging assets for security and application teams to defend. The stakes have never been higher for security teams, a recent IBM study from 2024 indicates that it costs a large enterprise an average of $4.88m to remediate a security breach, up 10% on 2023.

Securing APIs is now a recognized key area of focus for cyber security teams and a category of software, which Gartner defines as:

API protection products protect APIs from exploits, abuse and access violations, and assist in remediating API exposures. These products perform API discovery and posture management and provide runtime protection.

Enterprises have been investing in commonly called API discovery tools for some years now, believing that they were addressing all their API security needs. Sadly this is patently not the case as despite these investments, the volume of attacks and breaches continues, the risks have not diminished, and if anything with the advent of AI and LLMs, they are set to increase even further.

Why are API breaches still happening? 

In reality, API discovery reflects only one dimension of API security and is not the be all and end all. Nevertheless, it is a valuable exercise to gain visibility of all APIs in the enterprises, however, in order to generate a truly comprehensive API inventory that will ensure security has an accurate view of the attack surface and understanding of API activity, where do they start?

API Discovery – where is the starting point?

My Irish colleagues always love to tell me the well known joke about a tourist in Ireland who asks one of the locals for directions to Dublin. The Irishman replies: ‘Well, if I were you, I wouldn’t start from here’. The same rule might apply to security teams seeking to gain  better visibility and understanding of all their APIs.

Unfortunately, security professionals at large enterprises rarely, if ever, have the luxury of a greenfield deployment and so must contend with wrapping their “governance arms” around a sprawling estate of APIs that have been introduced to the business from many different sources. Those APIs could be from distributed development teams across different geographies, new APIs inherited as a result of a company acquisition, or simply the introduction of a new mobile app driven by APIs. By gaining an accurate view of the attack surface and understanding their API activity, security can better govern the enterprise’s API security posture going forward.So just where do security teams need to look in order to build a comprehensive API inventory?

Fig 1. The Wheel of API Inventory

Developer Code repositories and API Discovery

According to Postman’s 2023 State of the API Report, a global survey of API development teams at enterprises, 49% of respondents said most of their organization’s development effort was spent working with APIs. That number can vary, depending on the industry with as much as  57% in financial services or as low as 24% in manufacturing. Regardless, the key point is that development teams know what APIs are current and where the code is stored. Developer code repositories such as GitHub and GitLab catalog APIs by indexing and organizing them based on metadata, such as the API name, version, endpoints, documentation, usage patterns, and tags.

Internal Developer Portals and API Discovery

Internal developer portals are designed to enhance the development process by serving as a one stop shop for internal teams to access everything they need for software development and operations. Naturally they include APIs, microservices, code repositories and host of other dev-centric services.

API Development and Security Testing and API Discovery 

A new category of API security tooling has emerged to enable a proactive, security as code approach, that facilitates development teams with design and testing tools that run from within their IDEs and CI/CD pipelines. Analogous to the traditional SAST and DAST tooling for application security, vendors such as 42Crunch have pioneered this category with our API security platform. Leveraging the OpenAPI Specification as the basis for API definitions, developers can quickly import APIs from their code repositories, work on them in the IDE and publish to the CI/CD pipeline. Here security teams gain full visibility of all APIs scheduled for production and can ensure governance is administered and enforced centrally across all APIs.

API Portals and Gateways and API Discovery
The API inventory building process often involves integrating with API management tools, such as API gateways and portals that automatically scan and document APIs within the repository. The catalog might also include categorization by functionality (e.g., authentication, data retrieval), allowing developers to quickly search for and find APIs relevant to their needs. Gateways monitor traffic, gather metadata and provide centralized dashboards for easy discovery and management.

The API portal catalogs APIs by organizing, documenting, and presenting the available APIs in a structured and user-friendly way to make it easier for developers to discover, understand, and consume the APIs. APIs are listed in a searchable and browsable interface. Developers can find APIs based on names, tags, categories, or specific functionalities.

Functional Integration and Testing and API Discovery

Just as development teams maintain a code repository to govern the evolution of their code, each enterprise has a QA team with functional and integration tests to ensure that the API implementation performs as expected. These teams have a deep understanding of the enterprise’s API landscape and use tooling, such as Postman and SwaggerHub, as resources to manage their work and test the APIs. Such tools test not only the path and the HTTP method but also valid request and response data including all relevant headers and parameters. Asking your QA teams to feed into the API Discovery process is a great way to enrich your understanding of the risk an API might expose.

API Runtime Logs and API Discovery

API runtime log tools are designed to discover APIs by monitoring application traffic and analyzing the data flows between services. These tools inspect data flows across the network and application layers to catalog APIs.  While they may record undocumented APIs or “shadow” and “zombie” APIs, security teams should never be lulled into a false sense of security by believing that once documented, they are therefore secure. These tools will identify APIs, but do not expect them to be the panacea to testing, remediation and runtime policy enforcement challenges.

42Crunch Recommendations:

If security teams are to achieve true visibility and governance of their API estate and create an inventory that is up to the minute at all times, then they need to adopt a proactive approach to the cataloging and indexing of their APIs. Some essential steps to adopting such an approach are listed below:

• Build an API Inventory. Conduct an initial API discovery exercise by engaging with your application and API development teams to understand what code repositories and API management infrastructure is already in place. From here you will be able to quickly gain an appreciation for the API design and development processes and understand where any gaps may lie.
• Prioritize which APIs to Protect. By prioritizing which APIs you wish to protect, security teams can get a head start on improving the business’ overall security posture. Start with your most critical APIs, identifying any that may carry sensitive data. E.g. endpoints handling delicate information such as PII (see reference above).
• Automate security posture management. Adopting tooling that enables security to automate API security rule enforcement from the CI/CD pipeline allows you to scale the security enforcement as your inventory of APIs grows. You avoid the traditional bottlenecks, manual intervention and false positives associated with traditional application security tooling.
• Adopt OpenAPI specification as the source of truth. Being context aware is central to the efficacy of any API security strategy. Adopt tools that enable continuous runtime protection and identify new APIs and alert security when a new API is deployed.
• Conduct API Risk Assessments at Design and Runtime.  Quickly and easily conduct an audit of every API to assess its risk posture. Identify vulnerabilities and misconfigurations at design time to avoid rollout of unsecured APIs.
• Quick start by identifying unknown APIs at runtime. If speed is of the essence and APIs are already deemed potentially vulnerable, without having any sight of them, then deploy a runtime schema protection tool such as API Protect from 42Crunch to identify all APIs other than those permitted by security.

API Discovery ≠ API Security

I regularly encounter security teams that have created a very comprehensive API inventory and like proud parents explain how they have identified undocumented zombie and shadow APIs. But the next question they pose to me is, now what? We have a list of endpoints but have no way of understanding the business logic and workflows associated with these APIs. Business context is essential when securing APIs because it helps align security measures with the specific needs, risks and goals of the business.

Take for example the OWASP API Top 10 risk of excessive data exposure which is relatively simple to exploit, yet bypasses API runtime log tools. A hacker sniffs traffic, looking for sensitive data exposure that should not be returned. Without the ability to review and enforce controls on the schemas being created, the API is potentially vulnerable.Equipping security with the correct testing and runtime protection tooling ensures that company APIs are protected.

Thankfully the OpenAPI specification (OAS), also known as Swagger, is the universally recognized standard to enable companies to define and implement this logic at API design time. Platforms such as those from 42Crunch have been built from the ground up to empower development teams quickly and easily leverage OAS as they code and assist  security teams enforce this standard at runtime.

In my next blog post we’ll explore in depth the requirements for implementing an exhaustive API Security program including API testing, API Governance and API Protection throughout the life cycle of the APIs.

¹ https://www.ibm.com/reports/data-breach
² https://www.postman.com/state-of-api/