API Attack Surface

In this article, you’ll learn the following:

• What an attack surface and an API attack surface are
• What recent research says about both and how you can manage them
• What are some fundamental components of API attack surface management
• What makes API attack surface analysis differ from attack surface management
• The merits of automated penetration testing in reducing the API attack surface
• The value of shifting left in reducing security risks

What Is Attack Surface?

An attack surface is all the entry and exit points through which malicious actors can get in and out of an information system, taking out sensitive and private data or causing other types of damage.

More elaborately, the attack surface comprises the code that protects the system, as well as the paths, i.e., exploitable vulnerabilities and exploitation techniques leading into and out of a system.

By “the code that protects the system,” we mean security measures such as authentication (implemented through code) or data encryption (likewise) that can become part of the problem instead of the solution if not executed properly. Hence, they, too, make up and enlarge a system’s attack surface.

It’s worth noting that the types of users who access the system and their privilege and permission levels also fall within an organization’s attack surface. User access misconfigurations often result in successful cyberattacks and terrible experiences for the targeted organizations.

One way to divide an attack surface is into digital and physical. Web applications and APIs, for example, fall within the first type. In contrast, mobile devices and workstations fall within the second.

Another way is to divide an attack surface into external and internal. An attack scenario where a state-sponsored threat group like Sandworm hacks a power grid is an example of the first. A scenario where resentful employees, infiltrated malicious agents (yes, it does sound like a conspiracy), and ill-willed partners hurt a company, on the other hand, is an example of the second.

Malicious actors can access systems in many creative ways via:

• User interface
• HTTP header
• Database
• Email
• API

Common attack vectors, that is, attacking methods to abuse these are:

• Ransomware
• Phishing
• Man-in-the-middle
• Malware
• Long-forgotten dormant API endpoints

The size of an organization’s attack surface depends on many factors. For starters, the more code, the larger the attack surface, meaning complex systems with masses of code are more prone to cyberattacks.

Any significant IT infrastructure change inside an organization—from adding new mobile devices to migrating to the cloud—can also affect the attack surface.

On a general plane, the dramatic developments in telecom, the popularity of microservice architecture, and the all-encompassing digital revolution have all contributed tremendously to the increase of the global attack surface.

“The state of attack surface management 2022” showed that 67% of organizations experienced expanded external attack surfaces. Attack surface expansion was No. 1 on Gartner’s list of top security and risk management trends for the same year.

A more recent 2023 research from TechTarget’s Enterprise Strategy Group tells a similar story: “62% of organizations’ attack surface increased” in the last 24 months.

APIs Are Magnificent, but They Extend Your Attack Surface

Without APIs, today’s widespread digitalization and microservices would’ve been hard to imagine.

APIs have proven pivotal in digitalizing industries and entire economic sectors. Thanks to increased API adoption, automotive, banking, utilities, telecom, and healthcare have all taken giant steps toward a highly convenient and inventive tomorrow.

An application with a microservices architecture means small, independently functioning, highly scalable software components that communicate with each other through APIs. For instance, a user microservice talks to an authentication microservice to confirm the user’s identity before returning the user’s profile information.

Over the years, microservices and APIs have become so tightly related that API growth has gone hand in hand with microservices’ growth and vice versa, at least since the advent of Docker in 2013.

Today, APIs are so prevalent—and there’s no good reason to think we’ll stop proliferating them—that if there’s a single risk factor in the future that’ll contribute massively to the enlargement of the attack surface, that’ll most likely be insecure APIs.

In 2019, Gartner predicted that 90% of web apps would have a larger attack surface area in insecure APIs than in UI (user interface). If we look at what’s happening right now, that’s precisely the direction in which the story unfolds. Both ethical hackers and threat actors bypass the UI to abuse systems through vulnerable APIs.

This last point entails much more than the apparent. APIs are in a unique position to cause as much harm as they do good if not suitably secured due to their role as the main connective tissue in information environments. The degree to which they can affect systems has shown again and again to be detrimental.

A clear example was one of the power outage cyberattacks by Sandworm, the uber-sophisticated hacking group notorious for its cyber-caused blackouts.

In 2022, Sandworm took advantage of an obsolete API in a MicroSCADA control system to move laterally in the victim’s information environment, eventually opening a substation’s circuit breakers and causing a massive blackout in Ukraine.

In this cyberattack, as in myriads of others, the threat actors were not after the API. Instead, they targeted underlying systems or data accessed and carried by the APIs.

Good-to-Know API Attack Surface Stats and Findings

The 2023 “Securing the API Surface Attack” report by Enterprise Strategy Group revealed that:

• 26 is the average number of APIs that midsize and enterprise-level organizations use per application. Since organizations of this size rarely use a single application, we can safely assume that the number of APIs per organization is much higher than 26. (If that’s not proliferation, nothing is.)
• 36% of the organizations state that all their applications rely on APIs.
• 35% release API updates daily, and 40% weekly.
• 67% use open public-facing APIs.
• 57% of the organizations experienced multiple API security incidents, and 35% at least one in the 12 months before the survey.
• Data exposure and account takeover were the top two security incidents.
• Negative impact on shareholder value or brand standing is among the top incident consequences.
• Authentication is a top concern for most organizations.
• API visibility is a grave challenge, along with API management tool sprawl.
• Manual testing and processes are currently prevalent despite being clear that they’re not feasible in the long term.

On the brighter side:

• Most organizations say they can respond to an incident within hours or one day.
• The majority have dedicated API security budgets, and many expect to invest more in API security, specifically in specialized tools.
• Half of the organizations see data classification as the most important capability in an API security solution. Blocking high-volume or malicious traffic comes second, and addressing the OWASP API Top 10 Security Risks is third.

One counterintuitive revelation of the report was that the surveyed organizations used various security solutions—WAFs (web application firewalls), API gateways, and even purpose-built API security tools—yet many experienced incidents multiple times a year.

One explanation for this paradox is that existing and established tools are lacking in some segments. WAFs, for instance, have repeatedly proven inadequate as API security solutions.

As for the other solutions, it is the responsibility of vendors to make adjustments or fill the current gaps to ensure that, if used properly, their security solutions do their job extremely effectively.

API Attack Surface Management

API attack surface management includes, among others, the following three fundamental aspects:

• Inventory management
• Vulnerability management
• Penetration testing

API Inventory Management

API inventory management, a crucial aspect of strengthening the API security posture, means neatly cataloging all the APIs and API endpoints in your information environment. “All” implies that, ideally, you should have complete knowledge of each API.

However, sometimes, in large environments, this is easier said than done, especially if an organization:

• Has manual cataloging processes
• Does not update inventory together with API updates and upgrades
• Lacks continuity in inventory management, for instance, due to employee turnover

Purpose-built API security solutions often come to the rescue with functionality that helps with API inventory management.

For instance, Equixly relies on your API’s OAS (OpenAPI Specification) definition file, machine learning, and giant wordlists to probe the API and look for shadow endpoints. If it finds unidentified endpoints, it returns a new, patched version of the OAS file with the differences, i.e., previously undocumented API endpoints included.

Speaking of “undocumented,” API inventory does not mean only a list of the exact number of APIs. It also includes:

• Comprehensive documentation, meaning no blind spots, such as the lack of information on the current API version, the purpose of an API host, or the API retirement process
• Data classification, meaning accurate understanding of the API endpoints that operate with sensitive data such as PII (personally identifiable information) and PHI (protected healthcare information)

API Vulnerability Management

API vulnerability management is what you’d expect it to be: Dealing with security flaws, bugs, and vulnerabilities in your APIs.

The API community has the OWASP Top 10 API Security Risks as a trusted source of information on the most common and severe API security vulnerabilities. This list is based on research of API incidents in the wild and reflects the current state of affairs of insecure APIs.

When things change in practice, the OWASP (Open Worldwide Application Security Project) updates the list accordingly. OWASP has published two top-ten lists so far: One in 2019 and another in 2023.

Organizations should use the latest OWASP Top 10 API Security Risks as guidelines in their vulnerability management efforts but not as an exhaustive list of API vulnerabilities. Security professionals have already drawn attention to the list’s incompleteness and missed opportunities to raise higher security awareness of problems like injection risks.

Many API security tools and platforms offer vulnerability management features. Different solutions approach vulnerability management differently, but most scan and test for at least some of the top ten API security risks.

API Penetration Testing

There’s hardly a better method of finding the attack paths that hackers can exploit than API penetration testing.

We must emphasize that API penetration testing is not just a good-to-have variant of API security testing. The sheer size of today’s API attack surface demands that you include API pentesting as a separate item in your attack surface management program.

It’s becoming increasingly evident that regular and frequent penetration tests must become the norm, not the exception. The unique advantage of penetration testing is that it takes you to that vantage point that allows you to see and approach your APIs as hackers see and approach them, and there’s no substitute for the benefits of that perspective.

Pentesters can carry out black box and gray box tests.

In a strict black box engagement, testers do not receive any information on the attack surface of the target API. But, like black-hat hackers, penetration testers (ethical hackers) can choose among an array of options, such as Amass and other OSINT (open-source intelligence) recon tools, to discover as much of the API attack surface as possible.

In contrast, in gray box testing, pentesters have access to information that speeds up and simplifies the API security testing. For instance, they could be allowed to set up user accounts for testing purposes in addition to getting access to an API definition file.

Are there API security tools specialized in penetration testing, that is, ethical hacking? The answer is in the following section.

API Attack Surface Analysis

To map your API attack surface and understand your risk profile, you must perform API attack surface analysis, which is similar but not identical to attack surface management.

API attack surface analysis means discovering and remediating vulnerabilities specific to your API.

For instance, the OWASP API top ten list does cover business logic vulnerabilities—like BOLA, BOPLA, and BFLA—but each API is unique and requires a different approach to spot logic flaws. So, you cannot take a generic approach, relying exclusively on this list, if you want meaningful analysis results.

Typically, this is work done by security architects, penetration testers, and specialized API security solutions. Hence, there are two ways to do the analysis:

• Manually (penetration testers and security architects)
• Automatically (specialized automated solutions)

Let’s focus on automated API penetration testing. It’s easier to imagine a human pentester taking a (let’s use a marketing buzzword) personalized approach to your API. But how does a machine achieve this feat?

If we take Equixly again as an example, it relies on an OAS (XML or JSON) file to map your API. It then launches a stack of attacks based on the API specifications, testing various scenarios that can expose your API as vulnerable.

Equixly employs artificial intelligence to ensure efficiency. Thus, you have a an AI-powered hacker supporting your API attack surface analysis.

Some tools may also work for SOAP and GraphQL APIs, while others, like Equixly, work for REST APIs.

Whatever the case, the advantage of automated API pentesting is precisely that—automation. Automation implies speed, cost-effectiveness, and convenience. It turns penetration testing from a rare and potentially cumbersome process to a regular and quick affair.

Of course, it’s absurd to think that automated API penetration testing tends to replace human penetration testers. Nothing can match the ingenuity and expertise of a seasoned penetration tester.

However, as tools that supplement the pentester’s work, fill the yawning workforce gaps in cybersecurity, or make frequent testing possible, automated API testing solutions’ merits are hard to deny.

Reducing the API Attack Surface in Development

Integrating security into SDLC (software development life cycle) is probably the best way to reduce your API’s attack surface.

Recent research has confirmed more than a few times that shifting left, that is, including security as early as possible in API development, has become necessary. The point of the shift-left approach is to prevent rather than cure API security vulnerabilities, which decreases the time and resources you need to mitigate or remediate risks.

Giving developers targeted instructions on fixing unused paths and securing shadow APIs and parameters is how security testing can help reduce the attack surface.

This proactive approach implies following security best practices in development and including API security testing in the CI/CD pipeline.

Formal API security training for developers goes hand in hand with confidence in their ability to implement secure development practices, so that’s a viable way to address the first requirement.

Testing and scanning your APIs continuously for vulnerabilities—whenever developers write new code but before they deploy it—addresses the second.

Final Thoughts

The across-the-board digitalization, microservices architecture, and API proliferation have dramatically extended today’s attack surface. The API attack surface itself is increasing noticeably every year.

Even though the growing number of APIs doesn’t have to lead to a larger attack surface, that’s exactly what’s happening. Short deadlines, missing structured development processes incorporating security best practices, shortage of developers’ security training, and lack of security testing in development are some of the reasons why.

Get in touch with Equixly to see how you can benefit from regular penetration testing and an API-powered hacker in your security stack. We’d be happy to talk with you.

Carlo De Micheli

Director of Product Marketing

Carlo is a versatile professional with extensive international experience. His enthusiasm for innovation extends across cybersecurity, automotive, and aerospace, where he actively engages in pioneering projects. Holding a technical background in aerospace engineering and supplementing it with independent studies in programming and security, Carlo has organized and presented at international conferences and established tech startups related to the sharing economy and fashion before embracing marketing and sales.

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.