Discover TÜV-certified GoogleTest with Agentic AI for C/C++ testing!
Get the Details »
Whitepaper
Curious what’s in the guide? Start with the preview below.
Today’s adversaries are goal oriented, whether that goal is stealing trade secrets, personal information on consumers, or harming a business through a denial-of-service attack. Finding zero-day vulnerabilities and attacking custom applications is hard. A simpler attack vector is always preferred, whether that’s attacking a supplier in a supply chain with poor software security practices, tricking a user into revealing insider credentials, or exploiting a known vulnerability in a common open source software component.
APIs represent over 80% of all web traffic and offer attackers similar attack techniques as vulnerable open source software.
Often, the problems leading to API-related breaches are not because the attacker (and in some instances security researcher) is particularly clever or diligent. Instead, many of the issues are related to poor design and implementation of the API.
Central tenants of software security are strong authentication/authorization, the principal of least privileges, and data protection, as well as to test for both abuse and misuse cases. Recent security exposures at Clubhouse, John Deere, and Experian are examples that show how basic software security practices were not followed, leading to leaked information on users, customers, and consumers.
"Poorly designed APIs can disrupt businesses and erode confidence in consumers especially when they expose privacy issues."
—Security Solutions Expert at Parasoft
"Poorly designed APIs can disrupt businesses and erode confidence in consumers especially when they expose privacy issues. The Clubhouse API vulnerabilities that allow ghosting, trolling, and eavesdropping are examples of why security must be designed in and follow sound software engineering practices where least privilege is a core building block to eliminate a class of security issues," explains the security solutions expert at Parasoft.
In each case, the security researchers who identified the vulnerabilities simply used the API—as it was designed—to access information on millions of users and/or customers, as well as misuse and abuse the intended functionality in the API. Some of the API designs were open to any user without authentication and provided the ability to look up any (or all) users and download names, addresses, purchases, and other information. These were avoidable errors in the design, implementation, and testing of the APIs.
A well-designed API requires input from product owners, architects, and security to properly understand abuse and misuse cases to design security in. Using the examples above, authentication controls are critical since the authentication mechanism is exposed to everyone, including an organization’s adversaries.
Authentication controls, therefore, go beyond simply requiring users and systems to authenticate. They include controls to prevent credential stuffing and brute force attacks, weak passwords, revealing sensitive information like auth tokens and weak encryption keys.
Strong authentication controls are only a first step. As noted by the OWASP API Security Top 10, organizations need to also ensure proper authorization at both the object level and function level.
API discovery is essential. Visibility to all APIs is required. One cannot secure something without first knowing it exists. Understanding the attack surface and which APIs are exposed is essential for security testing. API test coverage and discovery are important data points to minimize risk associated with API attacks. As mentioned, the shift from monolithic applications to microservices has greatly increased the number of API in the average organization. This fundamental shift will require organizations to be more proactive in their API discovery and attack surface analysis.
In best practice, software projects include detailed documentation for internal parties to simplify maintenance and help developers new to a project understand how the application works. Likewise, APIs require documentation for dev using the API, whether internal developers and testers or third parties. In reality, pressure to add features and accelerate time to market often means documentation is limited.
This is especially true with APIs, which are usually simpler and intended for internal use. Without proper internal docs, DevOps engineers have imperfect knowledge on how an API works. Without API contracts, definitions, and specifications, QA and security are left to model the intended behavior of APIs and guess use and misuse cases.
Security resources are scarce in most organizations. It’s a growing national issue. QA and DevOps engineering are usually focused on functional testing, ensuring the features listed in the requirements document perform to specifications.
While this includes use cases like throughput and capacity testing, it can miss security tests that often focus on abuse and misuse cases, such as, calling an API with intentionally wrong arguments or not properly handling the values returned by the API.
Security and testing are often familiar with use cases for a user interface. API use cases are more complex, in particular between microservices.
While the security issues and exposures previously mentioned above are straightforward, the rapid increase in microservices and resulting APIs complicates security, potentially allowing sophisticated attackers to link multiple APIs in a multistep attack. Access control policies with different hierarchies, groups, and roles can be confusing to defenders and lead to inadequate security controls.
Testing and securing APIs require an understanding of an application’s logic about which security often has less information. APIs are more like Lego blocks that can be assembled in a variety of ways. Adversaries may use APIs in unintended ways—even linking APIs to attack an application—like how many ways can one reach the shopping cart or store payment information?
"APIs are surprisingly flexible. Being able to fully test possible combinations is critical to making sure that your APIs are secure."
—Arthur Hicken, Chief Evangelist at Parasoft
Complete testing requires programmatic visibility to the APIs and their interactions, edge cases, protocols, and knowledge of expected data types. Creating tests is possible with sufficient resources, of course, but this skill has a very steep learning curve.
Traditional tools used in traditional ways are only a partial solution. Static analysis tools typically examine source code. While these tools identify some issues with API, they lack knowledge of intended functionality, which limits their completeness.
Dynamic analysis scanners also help, but often only look for entry points in the user interface and may have no awareness of APIs and their functionality.
While it is possible for a skilled pen tester to identify weaknesses in APIs, it scales poorly and isn’t practical from a time and cost standpoint. It’s also incompatible with rapid development methodologies like CI/CD and DevSecOps.
These tools don’t understand API authentication mechanisms and need to be aware of protocols such as OAuth2 and JSON Web Tokens.
They also struggle with content types and HTTP responses that impact how vulnerabilities in APIs are detected. In addition, there are no links these tools can crawl to discover APIs, which fundamentally changes security testing for APIs.
Adding API security testing to the software development life cycle is possible, even in rapid development environments, when organizations provide DevOps engineers with the correct tools and support.
Importantly, security testing must consider common design flaws as well as implementation and configuration errors. Building more secure software is not a secret. There are several guidelines and standards organizations can use to identify and mitigate risk.
One, the OWASP Application Security Verification Standards (ASVS), is particularly helpful when considering designing and implementing APIs. ASVS describes itself as "a list of application security requirements or tests that can be used by architects, developers, testers, security professionals, tool vendors, and consumers to define, build, test and verify secure applications."
While achieving ASVS certification is an admirable goal, organizations seeking to incrementally improve their software security programs can use ASVS guidelines in a less formal way.
Integrating API security activities early in the software development life cycle is possible, even in rapid development environments, when organizations provide their development teams with the correct tools and support.
Security testing early is essential for preventing and detecting security issues with APIs, but everything starts with a good design. Designing a secure API is not a secret. Among other things, APIs require clear definitions for the parameters allowed by security controls, rate metering to prevent brute force attacks, and enforcement of strong authentication mechanisms to prevent API misuse.
Postponing security testing until late in the software development life cycle results in delays and higher development costs. Fixing bugs becomes more expensive in the maintenance phase. The rising costs are due, in large part, to the difficulty of refactoring software to fix bugs or change open source libraries, while maintaining the features and functionality of the original design.
In the ASVS standards, shifting left considers API functionality, authentication, and authorization in the design phase of the life cycle. This entails authenticating communication between application components, including APIs; all components using least privilege principles; encrypting calls to APIs; and API URLs not exposing sensitive information such as session tokens.
OWASP provides guidance through the OWASP API Top 10, which describes the consensus opinion on the most common and damaging vulnerabilities found in APIs. Many of these are concerned with identity and access management issues, while some like Injection and Logging issues are already used and integrated in most application security testing suites.
A better method for testing APIs is to leverage functional testing to provide visibility to the APIs underlying the application and their functionality, and augment test generation using artificial intelligence (AI) to build appropriate test cases.
"API testing can be surprisingly complex. It requires knowledge of testing, how the APIs are used, and how they could be used in different ways than the user stories. When you add security to the mix, you need even more knowledge because again the API layer is deeper and more technical than the UI layer," explains Arthur Hicken, Chief Evangelist at Parasoft.
"API testing can be surprisingly complex. When you add security to the mix … the API layer is deeper and more technical than the UI layer."
—Arthur Hicken, Chief Evangelist at Parasoft
Parasoft SOAtest’s Smart API Test Generator leverages a browser plugin that uses AI to automatically convert manual and automated UI tests into automated API tests. Instead of simply collecting traffic, recording it, and playing it back, Smart API Test Generator applies AI to discover meaningful patterns, apply threat models, and understand relationships between those API calls. It can then generate automated API test scenarios that perform the same actions as your UI tests but are fully automated and easily extendable.
Ready to dive deeper?
