One of our fintech customers recently said, “APIs are proliferating rapidly, much like mushrooms sprouting in a forest, and they’re appearing in the most unexpected corners within enterprise networks.”
And we couldn’t agree more.
APIs are being adopted and integrated so quickly that even the development teams creating them may not accurately guess how many APIs exist within their systems.
If the development and security teams don’t know the quantity and location of APIs in their systems, it becomes impossible for security teams to manage and test them.
Not knowing your APIs is the fastest way to succumb to a data breach, as a lack of visibility widens the attack surface by multiple folds.
Therefore, discovering and documenting APIs are fundamental steps in API security and protecting your systems from potential breaches caused by API vulnerabilities.
In this piece, we’ve outlined how you can do both efficiently and effectively without halting your development activities.
API Discovery involves creating a catalog of all APIs within an enterprise network, classified based on their functionality and type, enabling them to be monitored and secured effectively.
Many enterprises are aware of its importance and thus have begun taking strides toward maintaining an accurate and complete inventory of their APIs.
However, manual efforts have limitations even with tools like OpenAPI (formerly known as Swagger).
This delays application release and hinders business objectives, as Dev teams have to manually document and list APIs while also deploying code to production.
This effect is visible as 59% of surveyed enterprises have reported delays in application rollouts due to API security concerns.
Not only are manual efforts to maintain an inventory corrosive to business goals, but they are also ineffective and inefficient in the long term.
APIs are not static, they continually evolve throughout the product’s lifecycle.
So, should you abandon all discovery efforts if they aren’t yielding the desired results?
Not at all!
Instead, consider altering your approach to their discovery.
Discovering your APIs continuously and automatically is the only way to keep up with development while still securing your applications.
It is the only way to discover them with the necessary metadata (endpoints, parameters, data flows, Authentication schemes, etc.) across all environment types, especially in production.
This is where current scanning tools, which focus on IP address and host information, fall short.
These tools cannot discover APIs during runtime but focus on schema definitions in the documented design.
These tools also struggle to categorize APIs according to their types (external, internal, third-party). They cannot pinpoint which APIs expose sensitive data types like Personally Identifiable Information (PII).
Which is a major factor in assessing and mitigating API-related security risks.
Here are all the different types of APIs your discovery process should reveal:
Cloud-native designs and microservices architectures often result in large API ecosystems that function as digital supply chains. Due to their complexity, many APIs may go unnoticed by security teams. To reduce potential attack vectors, your automated discovery process should uncover all these APIs and endpoints, including those not present in API gateways and management tools.
Zombie APIs: Due to their complex and dynamic nature, many outdated or deprecated APIs exist in various versions. Attackers can easily exploit these endpoints. 54% of surveyed enterprises identified this as a top concern.
Compliance with industry standards such as PCI DSS and HIPAA requires enterprises to identify and protect the flow of sensitive data, such as Personally Identifiable Information (PII) or Protected Health Information (PHI), from their servers. Therefore, enterprises should ensure that APIs handling sensitive data parameters and payloads are identified during the discovery process. So, penalties and potential public relations issues from data breaches targeting such data can be avoided.
No enterprise application operates in isolation in today’s interconnected digital landscape. Increasingly, applications are being built by integrating services from open-source code, third-party Software as a Service (SaaS) providers, and acquired application packages. While an enterprise may not have security control over these APIs, it is essential to identify how many of them are present in an application along with their functionality.
The general notion implies - malicious attackers do not target internal (east-west traffic) APIs, they are thus left entirely unprotected. Last year, 8% of attack attempts were perpetrated against internal-facing APIs, so discovering internal APIs is essential to safeguarding them.
However, the discovery of customer-facing, internal, and partner APIs should not be limited to just production environments. It should also cover all non-prod environments like QA, UAT, staging, SIT, and pre-production to protect them from attackers who thrive in these environments, which often have zero to no security controls.
While API discovery is a crucial step toward API governance and security, it alone is insufficient.
Enterprises must also comprehend each API, its functionality, and the underlying business logic to evaluate the risks it presents accurately.
Such detailed information can only be obtained through API Documentation, which reveals each endpoint's functionality and AuthN and AuthZ protocols.
Each endpoint contains at least a dozen specifications, including:
Thus, developers can't write such specifications while manually adhering to production deadlines. Consequently, documentation is often created for only a few key APIs and tends to be lengthy, text-heavy, or visually complex.
While this may satisfy compliance requirements, it will negate all the other use cases of documentation, such as the ability to generate custom tests and monitor the change in your APIs.
A survey found that more than 60% of the interviewed enterprises updated their primary enterprises every month, with some updating it daily or weekly.
Yet only 12% of them updated their Swagger or OAS files weekly, and the other 20% had no regular update schedule.
As a result, 66% of surveyed enterprises have incomplete or missing documentation.
This causes the API drift to be worsened as developers reiterate the APIs, threatening your security posture.
Therefore, enterprises should automate the generation of API specifications, ideally in standard formats like OpenAPI, through a portal accessible to all developers.
Documenting automatically and continuously will ensure that AuthN and AuthZ don't leak into production, third-party APIs are not left misconfigured, and no API is sharing information more than needed.
Recognizing the challenges in the API lifecycle mentioned above, we at Levo have incorporated robust discovery and documentation capabilities into our platform.
These capabilities allow us to discover endpoints across all API types, frameworks, and languages without changing code or configuration!
These endpoints can then be automatically documented through runtime traffic, logs, and code and made accessible via a centralized API portal.
Just as we discovered and documented 5000+ APIs for a fintech client in a few days saving them quarters of manual work.
So if you too want to avoid such manual labor and the inevitable frustration automate your API discovery and documentation with Levo!
CTA: Book a demo to see it in action!