A Brief Guide to API Security Testing

API security testing means:

• Assessing APIs for exploitable security weaknesses, flaws, and vulnerabilities
• Evaluating the quality of employed security mechanisms, such as authorization and authentication
• Appraising APIs’ ability to withstand API-targeted attacks as well as cyberattacks in which vulnerable APIs play an auxiliary yet dangerous role

API security testing is a distinct and essential component of security testing. It is integral to security risk assessment, mitigation, and overall management.

Why Separate API Security Testing?

While other types of API testing, such as integration and unit testing, are well incorporated into the development process, security testing has yet to see the same level of integration in many organizations.

The 2022 State of APIs survey revealed the distressing fact that security testing accounted for only 4.0% of API testing resources in organizations worldwide. Functional, integration, and acceptance testing were the three most prevalent types of API testing performed by the respondents.

For context, the results were based on 850 responses from professionals from more than 100 countries. Many respondents were developers working for organizations of various sizes.

These stats leave us with our jaws dropped. Organizations must integrate security testing much better; 4% is disproportionately low. Even if the situation has improved in the last two years, radical improvements are difficult to imagine, especially considering the constantly growing number of API security incidents.

How is it possible that APIs, a pivotal component of the current pervasive digitalization of economic sectors, receive so little attention regarding security?

We’re speculating, but one reason could be the sentiment that the other types of API testing—e.g., functional, integration, acceptance, performance, and load testing—somehow cover security or are simply sufficient to ensure uninterrupted API operations.

Another reason could be that both developer and security teams are overloaded with work and pressured by deadlines, so organizations make a tradeoff at the expense of API security testing.

Whatever the reason, one thing is for sure: Security testing is different from and irreducible to any other form of testing—whether that is another type of API testing or application security testing—and, as such, is more than necessary for unbroken API and organization operations.

One crucial difference between security and other types of API testing is the focus. We carry out security testing based on actual known API vulnerabilities and security risks, such as server-side request forgery (SSRF), improper inventory management, unsafe consumption of APIs, broken object property-level authorization (BOPLA), and similar.

The testing process revolves around this axis. The discovery of security vulnerabilities is not incidental or secondary to the process. We’re not first assessing the API’s functionalities and then discovering subpar security mechanisms that lead to functionality issues.

Instead, we search and probe primarily for security problems and are only then concerned with how they affect the API’s functionalities. It goes without saying that this distinction is somewhat artificial—the reality is more complex and ambiguous—but it serves the explanatory purpose.

Since the release of the first OWASP Top 10 API Security Risks list in 2019, we have a specialized API cybersecurity framework upon which to build our API security program, with security testing as a critical component.

OWASP, the Open Worldwide Application Security Project, recognized the unique nature of API security challenges, carried out thorough research of actual reported API security incidents, cyberattacks, and bug bounties, and created guidelines for the most common and severe API security risks or vulnerabilities.

The second crucial difference is that in security testing, we adopt the perspective of the enemy, that is, the threat actor/hacker/attacker. We don’t just test the API by exposing it to all the possible scenarios in which it must endure through users’ requirements, whether baseline or anomaly scenarios. Our approach is not the user’s approach.

Instead, it is the approach of someone who intentionally wants to harm or abuse the API and resorts to all sorts of creative as well as malicious practices to achieve that. This approach is missing from other API testing types, and rightly so, since their principal concern is not the security of APIs.

API Security Testing and DAST, SAST, IAST, and SCA

The chances of learning about API security testing without encountering the terms “DAST,” “SAST,” “IAST,” or “SCA” are quite slim. Hence, what would a discussion of API security testing be without space dedicated to them?

DAST

DAST stands for dynamic application security testing. It falls within the category of black box testing, meaning the tester doesn’t possess information on the target’s code base, design, structure, and attack surface. You can run it in different environments.

DAST assesses the target’s security in an operating state, that is, at runtime, which is why it’s called dynamic. It helps you establish whether there are vulnerabilities based on the target’s responses to the sent requests.

Interestingly, DAST simulates attacks on the testing target, which makes it unique and especially valuable for security purposes.

DAST’s upsides include:

• It’s language- and platform-agnostic.
• It produces fewer false positives than other testing methods.
• It’s effective for identifying security misconfiguration.

DAST’s downsides are the following:

• It’s difficult to scale.
• It doesn’t work for API discovery.
• It lacks visibility into the code base.
• It’s slow.

SAST

The acronym SAST stands for static application security testing. It’s a white box testing method, meaning the tester knows the testing target’s inner workings—design, code base, and structure.

SAST is different from DAST in that it helps you find vulnerabilities in the source code. It analyzes the code without executing it, which is where “static” comes from.

In addition to finding security vulnerabilities, such as input validation issues, SAST also allows you to discover design flaws and programming errors, such as syntax mistakes.

SAST’s strong sides are:

• It enables you to analyze source code extremely fast, much faster than human experts.
• It works well for finding basic errors in code that deviates from secure coding practices.
• It’s easy to implement.

SAST’s drawbacks include:

• It throws numerous false positives.
• It’s language- and framework-dependent.

IAST

IAST, or interactive application security testing, is somewhere in between DAST and SAST.

Like DAST, this testing method includes interaction with the testing target at runtime. However, like SAST, it also contains elements of white box testing, with testers having access to the testing target’s code base, data and control flows, and system configuration.

You can perform IAST in both development (continuous integration and continuous delivery, aka CI/CD) and production environments.

IAST allows you to find security vulnerabilities, like hardcoded unencrypted API keys and unsanitized user inputs, and observe the testing results in real time.

IAST’s benefits are the following:

• It provides quick, real-time results.
• It’s suitable for microservice build.
• It doesn’t disrupt the development process.

IAST’s drawbacks include:

• It’s programming language-dependent.
• It’s complex to implement since it requires the installation of special sensor modules/agents.

SCA

Software composition analysis is slightly different from the previous three testing types. It’s concerned primarily with vulnerabilities in third-party libraries and components. It enables you to inspect software aspects such as source code, containers, and binaries.

SCA analyzes the testing target’s design and examines its dependency tree. The results report on present libraries or frameworks with known vulnerabilities.

SCA’s strong sides include:

• It has a low risk of false positives due to it reporting only on known vulnerabilities.
• It’s exceptionally time-efficient.
• It’s tremendously helpful in creating a software BOM (bill of materials)—a catalog of components relied upon by the testing target.

SCA’s weak sides are the following:

• It finds only open-source vulnerabilities, not proprietary ones and those inadvertently introduced by your developers.
• It hinges on incomplete databases of known open-source vulnerabilities, which implies that it misses unknown vulnerabilities in the wild.

Beyond DAST, SAST, IAST, and SCA

Discussions of these four types of testing often lead one to believe they’re types of API security testing. However, while we cannot deny their merits for APIs, DAST, SAST, IAST, and SCA are not API security testing per se.

The four security testing methods were developed for another context, Web AppSec, and are not fully suited for APIs, just as APIs are not the same as web apps.

What? Then, why did we spend so much time talking about them? It’s counterintuitive and doesn’t make much sense, does it? True, it may appear like gibberish, but bear with us.

Our discussion of the four application security testing types makes sense in light of the following: API security testing includes elements of all four. To a certain extent, we can view them as the basis or precursors of proper API security testing.

From that standpoint, it’s important to understand how they work to understand the ins and outs of specialized API security testing.

Proper API security testing assimilates but goes beyond DAST, SAST, IAST, SCA, or any other application security testing type. It’s designed specifically for APIs—the way we develop them, the way they work, and the way we use them.

Types of API Security Testing

As far as API security testing types are concerned, we can talk about the following:

• API penetration testing (white box, gray box, or black box)
• API vulnerability scanning
• API fuzzing

Regardless of the type, API security testing can be manual, automated, or some combination of the two.

Manual testing is necessary, and we should never dispense with it. After all, there’s nothing like human expertise, regardless of the niche.

Still, organizations are increasingly adopting automated testing, including API pentesting, and for good reasons. Considering the current conditions, frequent and regular testing simply requires automation.

Manual tests tend to be slow, costly, and prone to errors. Add the dire cybersecurity workforce shortage to these—especially regarding technical API security roles—and frequent and regular specialized API security testing starts to look like a pipe dream.

API security experts have already voiced their thoughts on APIs being perfectly suited to automated testing and their support of eschewing manual efforts and integrating API security testing into the CI/CD pipeline—by definition, an automation process.

Given that automation relies on highly efficient and intelligent technologies that can work with tremendous volumes of data in a relatively short time span—such as artificial intelligence and machine learning—employing automated API penetration testing, vulnerability scanning, and fuzzing is a no-brainer.

API Security Testing Tools

Just like there are DAST, SAST, IAST, and SCA testing types, there are DAST, SAST, IAST, and SCA testing tools. Organizations have long resorted to these traditional application security tools to test APIs. However, practice has shown they’re inadequate for API security testing.

Some API security vendors talk about modern DAST (or similar), which can make things a bit confusing. However, that may be an example of using familiar terminology to refer to new technology or just a recognition of the use of DAST elements in the development of purpose-built API security testing solutions.

Whatever the case, the best practice is to use purpose-built API security testing solutions (with a strong emphasis on purpose-built). And it’s not hard to see why.

Just as you’d get specialized running shoes for adventure racing—not indoor powerlifting shoes unless you want to risk agonizing injuries—so you’d get a software solution tailored for API security testing if you’re going to test the security of your APIs.

The last few years have seen the emergence of a distinct API security software market, with a substantial portion of the solutions belonging to the API security testing category. This development is an inevitable and logical result of the global proliferation of APIs and the rise in API-related security incidents.

Organizations, especially large enterprises, necessitate the use of specialized API security testing tools to fill in security gaps and protect sensitive data accessed and exchanged largely by means of APIs. API security vendors are here to meet these needs.

If the API security testing tool you’re considering tests specifically APIs instead of HTML apps, these are some of the recommended qualities to look for when deciding for or against it:

• It should include security vulnerability/risk prioritization and offer remediation guidelines.
• It should be simple enough so inexperienced developers can use it with equal success as seasoned security experts.
• It should provide scanning functionality suitable for your type/types of APIs (REST, GraphQL, SOAP, or others).
• It should produce low alert noise, i.e., it shouldn’t throw an unacceptable rate of false positives.
• It should be able to integrate painlessly into your environment, work unintrusively, and perform fast enough not to impede the normal workflow of security and developer teams.
• It would be tremendously helpful if it included an AI or ML engine for increased work efficiency.

The following vendors currently offer prominent and high-quality API security testing solutions:

• Noname Security
• Bright Security
• Salt Security
• Traceable
• Wallarm
• APIsec
• Equixly

When to Test?

With the shift-left approach becoming growingly popular, and justifiably so, the obvious answer to this question is “As early as possible.”

Some experts say security should be included as early as the design stage of API development—before developers write the first line of code. Adding security later, after the API has already been designed and built, can lead to vulnerabilities and broken functionalities.

Currently, API security testing resembles the game Jenga. Developers build a tower, and after it’s built, security testers show up and start removing bricks, only to end up with the tower crumbling, requiring developers to rebuild it.

However, when security testing is well integrated into the development process, as it should be, security testers just direct developers to move bricks here and there. Devs do that, rearrange things a little bit, and the structure works perfectly. There’s no tower collapsing, no need for rebuilding, just a smooth, uninterrupted process.

More and more technical API security literature expounds the idea and embraces the practice of integrating security testing into the SDLC (software development life cycle). And the best locus for carrying out API security testing is the CI/CD pipeline.

Why test in pre-production, that is, development? For a simple reason: It allows you to discover security issues while they’re still easily fixable and enables you to cut many vulnerabilities at the root.

Early discovery of security problems saves time and resources—the two most valuable things for any organization and business. Addressing security issues while they’re still in their early phase is much simpler and less costly than fixing full-blown vulnerabilities in production, let alone a live environment.

However, API security testing must also be part of the production phase. That way, you can find missed security issues as well as weaknesses otherwise undiscoverable (e.g., production configuration issues).

How Does API Security Testing Work, and What Does It Achieve?

You can use OpenAPI (OAS), HAR files, or Postman collections for API testing. You can launch tests with, say, invalid requests to see how the API responds, trying to abuse the business logic flow and provoke unanticipated responses.

Or, you can use an automated security testing platform, such as Equixly, that utilizes a proprietary AI algorithm to fuzz the API and execute numerous attacks in a relatively short time.

However, for the purposes of this guide, we’ll shortly discuss a simple testing scenario for broken object-level authorization (BOLA). This security risk holds the unflattering first place on the 2023 OWASP API security top 10 list.

The first step is to find resource IDs by sending API requests and analyzing the responses.

The next step is to check if the discovered resource IDs allow you to request resources you shouldn’t be authorized to access. You can do this by creating multiple accounts and trying to access User B, C, and D resources solely with the User A token.

If you need more than just the resource ID to get the requested resource—say, a user or organization ID—to evade security controls, you can use a nested object. If the API processes your requests and you can manipulate other users’ resources, you’ve discovered a BOLA, which must be properly reported to the API owner.

This last part shows the whole point of carrying out API security tests. You test to find exploitable security issues, report them, and remediate them before threat actors discover and exploit them.

Instead of a report, hackers and cyber attackers generate mayhem in your information environment, which can cause operational disruption and, eventually, data, financial, or reputation loss/damage.

Final Thoughts

This guide defined what API security testing is and discussed why you need it.

In addition, you learned that DAST, SAST, IAST, and SCA are not proper API security testing types, and you need specialized tests and purpose-built solutions to secure your APIs.

You also learned when to test, what simple API security testing looks like, and what it achieves.

Contact us to learn more about this topic and discover in-depth details about API security testing with Equixly.

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.