{"id":77455,"date":"2022-07-20T07:36:20","date_gmt":"2022-07-20T11:36:20","guid":{"rendered":"https:\/\/staging.checkmarx.com\/?p=77455"},"modified":"2025-08-11T14:39:51","modified_gmt":"2025-08-11T12:39:51","slug":"what-is-your-api-attack-surface","status":"publish","type":"post","link":"https:\/\/checkmarx.com\/blog\/what-is-your-api-attack-surface\/","title":{"rendered":"What Is Your API Attack Surface?"},"content":{"rendered":"

The proliferation of APIs today is astonishing. According to a recent report<\/a>, the number of active APIs will approach 1.7 billion by 2030. You might expect that the majority of those APIs would be resistant to attacks or vulnerabilities; however, that is not necessarily the case. In fact, a major study from RapidAPI on the state of enterprise APIs<\/a> revealed a rather distressing lack of consistent policy enforcement and visibility across all APIs. Many of those APIs might expose parts that are undocumented, which is a great concern among security teams.<\/p>\n\n\n

This article explores the fundamental reasons why an API can become insecure and discusses ways to reduce the attack surface.<\/p>\n\n\n

\n<\/a>How Do Documentation Tools Like Swagger Fall Short?<\/h2>\n\n\n

Documenting APIs comes with inherent difficulties. The main problem areas include ambiguity of exposed functionality, incomplete or undocumented content, and incorrect responses. Development teams rely on tools like Swagger to help them document their APIs and use automation to mitigate some of those issues.<\/p>\n\n\n

Swagger is not a panacea, however, and using Swagger\/OpenAPI for API development does not protect you against all vulnerabilities. Recent research conducted by Soufian El Yadmani of Cybersprint<\/a> found many flaws in this technology, including many vulnerabilities listed in the OWASP API Top 10.<\/p>\n\n\n

For example, issues can happen when a web framework is integrated with Swagger. Developers using the FastAPI framework<\/a> can receive automatically generated Swagger UI fields from the code without declaring the API specification. This works fine on paper, but it might not work with your particular business requirements. The CRUD model might return a different result based on certain circumstances, for instance, or use a different way of calculating the end result that deviates from a typical case. The framework might be unable to introspect the correct result and rely instead on manual intervention. In this case, developers will have to completely own the dependencies and generated documentation to ensure that they match the expected outcome.<\/p>\n\n\n

In addition, Swagger generates complex code that has little opportunity for customization, which makes it inconvenient to use. For example, if hypermedia links are missing from the response, developers might try to intervene by writing custom queries that deviate from the spec, thereby increasing the risk of producing undocumented responses.<\/p>\n\n\n

Overall, the hardest part is establishing proper workflows for working with Swagger in the optimal way \u2013 writing specs in YAML, implementing the specs, and writing unit tests that conform with those specs. The API maintainer\u2019s job is to make sure that they don\u2019t deviate from the supported features and that they keep the spec as an authoritative source of truth.<\/p>\n\n\n

\n<\/a>Why It\u2019s Hard to Keep Track Of APIs<\/h2>\n\n\n

There are many reasons why APIs are hard to keep track of, and therefore hard to support at scale, but they all relate to technical debt. Working on many products as part of a broader ecosystem is a very typical scenario. Some parts of the system might be unknown due to a change in business priorities and focus, when some API services were neglected and forgotten \u2013 until they failed to work. This is an example of code ownership debt.<\/p>\n\n\n

Another type of technical debt is people debt. This happens when you allow developers to work on critical API systems for a long time and then they decide to resign from the company. The domain experience that these people acquired when building those systems may be lost to future maintainers unless there is a good handover process. Having many API services and no one who understands how they work significantly contributes to the initial problem.<\/p>\n\n\n

The issue becomes even bigger when you introduce architectural debt by implementing APIs using microservices. Let\u2019s explain.<\/p>\n\n\n

\n<\/a>How Microservices Architectures Lead to API Communication Flows<\/h2>\n\n\n

APIs and microservices are directly related. As you develop applications using microservices, you create highly decoupled services that enclose their own domain and communicate with each other using APIs. For example, a user microservice needs to communicate with the auth microservice to authenticate the user before responding to a request to view that user\u2019s profile. This communication dictates the use of an API contract between each microservice. In addition, API gateways can be used to aggregate multiple APIs under a single namespace, which helps maintain observability and centralized monitoring at a fundamental level.<\/p>\n\n\n

More real-world domains may need many microservices. In practice, that means having a separate API layer behind each microservice \u2013 and each one has its own attack surface. It\u2019s not unusual to have hundreds of microservices that each expose OpenAPI interfaces. This leads to what is known as API sprawl. In this case, the sheer number of services makes things harder to maintain. It\u2019s very common for businesses to use APIs without tracking when or where they are used, which makes it harder to keep track of their security risks.<\/p>\n\n\n

\n<\/a>Not Knowing All Your APIs Leads to Catastrophe<\/h2>\n\n\n

It is a well-known fact that you cannot secure something when you don\u2019t know it exists. But achieving continuous runtime visibility into all APIs is not trivial. It requires that you understand the exposed parts of the API in depth and that you document the obscure sections, run static code analyzers, and subject the application to security testing. This is mandatory, since the failure to record and secure these parts is very dangerous.<\/p>\n\n\n

APIs are already extremely susceptible to many kinds of attacks. Undoubtedly, there is no limit to what attackers can use when it comes to stealing sensitive data for malicious purposes. Here are some examples of attacks that you may encounter:<\/p>\n\n\n