API Penetration Testing

API penetration testing is the process of licitly accessing, attacking, and exploiting an API to expose its security weaknesses and flaws and discover vulnerabilities that pose a severe threat to the API and a consequential risk to the underlying information system.

A severe API vulnerability is to an information system risk what an earthquake is to a tsunami. Hence, penetrating an API can threaten your entire information environment, as infamous API attacks have shown.

In API penetration testing, or pentesting, the tester acts as a malicious attacker/hacker/threat actor would, but with one key difference. Unlike the threat actor, the tester carries out the attack with the consent and written permission of the API owner. For this reason, API penetration testers are also called ethical or white hat hackers.

API penetration testing involves:

• Identifying the API endpoints and attack surface
• Discovering and testing the security controls in place
• Launching specific API-targeted attacks to exploit the API
• Reporting the results to the API owner

API pentesting covers both client-side and server-side security issues.

API Penetration Testing and Web Application Penetration Testing

Although it can be argued that API pentesting is, essentially, part of web application pentesting, they are different in practice. The difference is due to the unique role that APIs play in modern application development and interconnection. APIs are a main, if not the main, vehicle for the digital transformation of today’s industries and sectors, from banking to automotive to healthcare.

APIs sit between disparate apps, programs, software components, and data sources, allowing them to communicate, exchange data, integrate, and scale. As such, they have a different structure and purpose from web applications and, hence, require a different security approach.

Renowned ethical hackers, such as Alissa Knight, have discussed and demonstrated the inadequacy of traditional web application security solutions like WAFs (web application firewalls) for safeguarding APIs. They have drawn attention to the different nature of APIs requiring the practice of separate penetration testing as an integral part of API security testing.

OWASP (the Open Worldwide Application Security Project), which is virtually synonymous with web application security, also acknowledged the distinct nature of APIs and created the Top 10 API Security Risks—a list of the most critical API vulnerabilities (different from OWASP Top Ten).

This list, along with OWASP’s security guidelines, has served as a framework for building and using separate API security strategies, measures, solutions, and testing practices within organizations’ cybersecurity programs. It plays a special role in API penetration testing as well.

Types of API Penetration Testing

Manual and Automated API Pentesting

Depending on whether a machine or a human professional performs it, API penetration testing can be manual or automated.

Manual pentesting is as it sounds. A human penetration tester, or a group of them, uses different techniques, relying on their knowledge and experience, to probe, attack, and exploit the target API and report the findings to the API owner.

In contrast, automated API pentesting is carried out by a machine, more precisely, a specialized software solution.

As the API security market is relatively new, the chances of stumbling across a legacy API pentesting tool are non-existent. That means that a purpose-built API penetration testing solution would typically include current, innovative technologies such as artificial intelligence and machine learning, adding to its efficiency.

When comparing the two types of testing, we can infer the following:

• Manual API pentesting can be more subtle and creative than automated API pentesting and lead to discovering potential vulnerabilities that automated solutions may miss.
• Manual testing can result in more in-depth, thorough reports that are invaluable to an organization’s security and compliance programs.

However:

• Manual pentesting’s effectiveness hinges on the expertise of the testers. Hence, the results can vary wildly depending on the level of proficiency of the pentester, which is not good since testing results should be reproducible. Otherwise, they appear arbitrary and inconclusive. On the other hand, automated testing renders much more consistent results that can only be improved over time due to technological and information updates.
• Automated API penetration testing is much more cost-efficient, that is, less expensive and time-consuming than manual API pentesting, as our research (section “Equixly by the Numbers: A Statistical Insight”) inarguably shows.
• Due to its speed and effectiveness, automated API pentesting is perfectly suitable for frequent API security testing. Conversely, due to its length and logistics, frequent manual testing is pretty much unfeasible.

The important thing to note, however, is that manual and automated penetration testing are both indispensable and complementary.

White Box, Gray Box, and Black Box API Pentesting

Based on how much information and access the tester receives from the API owner before the penetration test, API pentesting can be:

• White box: It emulates an inside attack, i.e., an organization’s insider going rogue. Accordingly, white box testing includes access to a user account, source code, and API documentation; knowledge of the API’s design and used SDKs; and maybe the freedom to circumvent network perimeter security controls.
• Gray box: This testing type mimics an outsider, i.e., a hacker, but a well-informed one. Usually, it means access to a user account and API documentation/definition file and possibly the freedom to evade some security controls.
• Black box: This type of testing emulates a hacker targeting an API with little to no knowledge of its inner workings. As such, it includes OSINT reconnaissance to discover as many details as possible about the target’s attack surface, such as relevant URLs, IP addresses, and API endpoints.

In principle, you can conduct these three types of testing both automatically and manually.

Keep in mind, however, that reality is more complex than the conceptual distinctions we’ve described here. Sometimes, a successful API penetration test requires a combination of black box and gray box testing, as well as combined manual and automated approaches.

API Penetration Testing Solutions

In the last few years, we’ve seen the development of many purpose-built API security testing solutions. A few of them, though, function and advertise as API penetration testing tools or virtual hackers.

Some prominent security platforms that offer an API penetration testing service are the following:

• Equixly
• APISec
• Astra Security
• Bright Security
• Intruder
• FireTail
• Akto

Of these, only the first three can be called specialized API pentesting solutions. One of them, Astra Security, combines manual with automated penetration testing services.

It’s worth noting that virtually all API penetration testing solutions combine pentesting with vulnerability scanning/assessment. Technically, they offer what Confidence Stavely, the renowned cybersecurity professional, refers to as VAPT (vulnerability assessment and penetration testing) in her book API Security for White Hat Hackers: Uncover Offensive Defense Strategies and Get Up to Speed with Secure API Implementation.

For an API security solution to be a good API penetration solution, it:

• Must be able to locate business logic flaws
• Must test for the OWASP Top 10 API vulnerabilities
• Must go beyond the OWASP API security top 10 list and search for vulnerabilities from databases such as CVE and CERT
• Must offer remediation guidelines
• Must generate detailed reports
• Must be able to perform without throwing considerable false positives
• Should integrate into the CI/CD pipeline
• Should support API definition files
• Should be able to find shadow, i.e., “hidden” APIs

How Often Do You Need an API Pentest?

To begin with, organizations, especially large enterprises, must carry out API penetration tests regularly. That said, a regular penetration test is not enough. Frequent testing, on the other hand, makes much more sense.

There’s a world of difference between regular and frequent security testing. A thorough and systematic API pentesting once a year is regular API testing. But it’s a far cry from frequent. And it is far from sufficient.

Recent compliance requirements have implied the importance of frequent penetration testing as well.

For instance, DORA (Digital Operational Resilience Act), Article 25 cites penetration testing as a requirement along with other types of software and security testing, such as vulnerability assessment and performance testing. These are not only possible but highly advised, if not necessary, to be conducted frequently, especially as part of the CI/CD pipeline.

What this implies for API security is that conducting an API penetration test, especially in the form of VAPT, frequently (not just regularly) is the recommended way to do API security testing. Moreover, frequent VAPT means automated pentesting can be part of the software development life cycle (SDLC) and integrated into CI/CD, which can pay high dividends over time.

The Role of API Penetration Testing in Vulnerability Management

The unique characteristic and main advantage of API penetration testing is that it sees and treats your APIs the same way threat actors do. Ethical hackers do not simply analyze APIs for security holes and faults but attempt to actively attack and exploit them, demonstrating the full, damaging consequences of neglected API security.

You may be surprised to learn that, in practice, most major API security vulnerabilities are discovered precisely through ethical hacking. That means API penetration testing has played a critical role in rooting out vulnerabilities. Accordingly, it must have a prominent role in your security vulnerability and risk management program as well.

Recently, the recognition of the security merits of API penetration testing has resulted in the publishing of pioneering technical API pentesting literature, such as Hacking APIs: Breaking Web Application Programming Interfaces and Black Hat GraphQL: Attacking Next Generation APIs.

This tendency has coincided with the launch of intentionally vulnerable environments—BankGround, vAPI, and crAPI—specially designed for API security pentesting practice.

These positive API security trends are already helping to increase the level of API security proficiency of security experts, enabling them not just to understand the concepts of API pentesting but also actively practice the various techniques of the art of ethically hacking APIs.

Examples of API Penetration Testing Techniques

API security experts and platforms use a wide range of techniques to conduct an API penetration test.

REST API Techniques

Sending thousands of requests to a REST API from a single account in a limited time is a technique that allows you to test for a security vulnerability like unrestricted resource consumption. If the target API accepts these requests without raising the alarm, you’ve found an exploitable API.

On the other hand, to test for security misconfiguration that leads to the exposure of sensitive data, you can launch an MITM (man-in-the-middle) attack. Misconfigured transit encryption resulting in an API transmitting data in cleartext would allow you to intercept requests and responses and obtain sensitive information, such as PII (personally identifiable information).

GraphQL Techniques

Even though REST APIs are by far the most widely used, other API technologies, such as GraphQL, have been gaining more momentum lately. Testing them may require a different approach.

For instance, the GraphQL specification lacks a detailed authentication and authorization standard, which leaves developers to manage this aspect on their own without proper guidelines.

An ethical hacker can take advantage of this generally problematic aspect when conducting a test. That especially applies if the target API has an in-band authentication and authorization architecture.

In-band architecture means implementing authentication and authorization mechanisms within the GraphQL API, which makes it complex and increases the probability of an authentication or authorization vulnerability.

Thus, the pentester can attempt to brute-force passwords by utilizing alias-based query batching in a GraphQL API with in-band authentication. If the API is protected behind a WAF, the tester can easily bypass this security control, find a valid password, and acquire a valid access token.

Automated Fuzzing

Automated fuzzing can be extremely useful in API penetration testing. The cybersecurity world understood the huge potential of fuzzing after the Heartbleed vulnerability in the OpenSSL library caused a widespread security crisis that could’ve easily been averted by using automated fuzzing in security testing.

Fuzzing means sending randomized inputs on purpose to provoke unexpected behavior or force the target API to crash. For instance, you can fuzz an API endpoint to find and then abuse valid user IDs. You can also fuzz wide to discover an improper asset management vulnerability or fuzz deep to bypass input sanitization.

Closing Thoughts

API penetration testing is unique in that it simultaneously gives you the perspective of an attacker and the ethos of a defender. It’s fundamental in managing security vulnerabilities and risks, securing sensitive data passing through APIs, and meeting compliance requirements.

Don’t neglect or postpone it, especially now with the advent of automated API penetration testing, which makes everything much easier and more cost-efficient for you and your organization.

Do not let the bad guys find what can hurt your APIs and information environment. See the cracks in your fortress first and hurt their chances of turning you into another sad piece of statistics of failed cybersecurity.

Contact us to learn more about API security penetration testing and the benefits of AI-based automation.

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.