Micro Focus is now part of OpenText. Learn more >

You are here

You are here

API security testing: Key tool trends—and pro tips to stay a step ahead

Jaikumar Vijayan Freelance writer

With API use proliferating rapidly within enterprise IT environments, concerns over API security have been growing as well. The trend is driving interest in—and an emerging market for—extending application security testing tool sets to include tools for automated API security testing.

A Salt Security survey released earlier this year showed that 91% of enterprises had experienced an API-related security incident over the previous 12 months. More than half (54%) of respondents said that they had discovered a security vulnerability in their APIs. Such issues have caused about two-thirds of organizations to delay release of an application into production, Salt Security found.

Setu Kulkarni, vice president of strategy at WhiteHat Security, said APIs today are facades to legacy systems that were never designed to be online or used in an the business settings they are today, leaving many organizations are just one vulnerable API call away from a major breach.

"API proliferation and API security, unfortunately, are on divergent trajectories. APIs are proliferating exponentially faster than the security testing of these APIs."
Setu Kulkarni

Tools are becoming available for organizations to test the security of their APIs. They range in capabilities from the immature and still developing to relatively sophisticated API-specific products, security experts say. The mileage that organizations will likely get out of them will vary quite a bit depending on the kind of APIs they have in place and the tools that are used to test them.

Here's a look at the tools, and five tips to get on top of API security.

The state of AP testing tools

Michael Isbitski, technical evangelist at Salt Security. There is some repurposing of static and dynamic analysis tooling from the web application world, he said, but these tools aren’t always as effective as they should be in the API space, so organizations need to be careful when using them. "Unfortunately, vendors have historically lagged with API-specific testing, he said.

"Traditional testing tool approaches may limit support to older API protocols like SOAP instead of the more common REST API or emerging GraphQL API types," Isbitski cautioned. Many testing tools are also designed to look for the types of weaknesses that are only relevant to traditional web application designs, he said. This can result in gaps for API security.

"Testing tools may also require too much care and feeding or subject matter expertise to run effectively."
Michael Isbitski

1. Test APIs through their lifecycle

As API-related breaches have become prevalent, teams are making some common mistakes when they implement APIs, said Sandy Carielli, a principal analyst with Forrester Research. As with application security, though, there isn’t a single spot in the software development lifecycle (SDLC) where an organization can secure APIs. "You need to test APIs throughout the lifecycle, paying attention not only to the API definition, but also to how it is protected when it’s deployed," she said.

To do that well, you need to first identify and understand all the APIs in your environment, Carielli said. "Pay attention to how the API is defined—what functions can be called, and what parameters are allowed," she said. Make sure that appropriate authentication and authorization mechanisms are in place, she added, because a lot of API-based breaches stem from insufficient permissions checking or because parameters are set client-side and can be easily manipulated.

Also vital is identifying the types of APIs you have, she said. 

"A lot of tools today focus on REST APIs, but many organizations still have legacy APIs like SOAP running in their environments. Do you have tools that will handle those legacy APIs, too?"
Sandy Carielli

Carielli said that, in some cases, SAST and DAST tools support API testing either as part of the tool itself or as a companion offering. "If your API security tools integrate with CI/CD pipeline tools, you can automate your pipeline by setting rules to file tickets or block deployments when the tools discover API flaws," she said.

Carielli advised that organizations should look for test automation opportunities post-deployment as well. "Many web application firewalls (WAFs) allow you to upload an API specification file and define traffic rules based on the API definition—disallowing any API calls that don’t match the specification," she said.

2. What to look for when selecting tools

Dylan Thomas, head of Fortify product management at CyberRes, a Micro Focus line of business, said that, when selecting tools, it is best to make sure you know what attributes to look for and what questions to ask. From a capability standpoint, he said, ensure that the testing tool can handle the unique challenges that APIs can pose, such as the ability to authenticate and maintain state for DAST- and API-specific attack vectors such as those outlined in the OWASP API Top 10.

You should also verify the tool's ability to interoperate with the existing environment, Thomas said, so you can consolidate findings from test points across the SDLC and, in addition, correlate them to accelerate triage, remediation, and reporting. Usability and scalability are two other key considerations, he added.

"How well does the solution integrate into the existing workflows and processes used by the key stakeholders, from developers to security to management?"
Dylan Thomas

You also need to consider how efficiently you can roll out the tools across the organizations and whether they have the flexibility to evolve as needed, he said.

Knowing the attack surface by reviewing documentation such as an OpenAPI spec or checking Postman Collections is just a first step, Thomas said. In addition, most APIs typically need to be tested in a specific sequence and with the appropriate data to identify potential security issues. This is where data from a Postman Collection—which is basically a group of saved API requests—can enable better testing compared to an OpenAPI spec, he said.

"Finally, most APIs require some form of authentication, which presents challenges due to the breadth of implementation protocols and the often dynamic, short-lived nature of tokens," Thomas said. Leading API testing tools will support a wide range of authentication methods, from bearer tokens to OAuth2, and automatically get re-authenticated as needed throughout the security assessment, he noted.

Daniel Kennedy, an analyst with S&P Global Market Intelligence, said companies are looking at point products that specialize in identifying and reporting on anomalous API behavior.

"While existing application protection approaches, such as provided by API gateways or WAFs, are helpful, many organizations are finding their security requirements are a little more sophisticated than multi-purpose solutions can address."
Daniel Kennedy

3. Find a good place to begin

WhiteHat Security's Kulkarni describes API testing as a four-step process:

  • API discovery
  • API onboarding and configuration
  • API testing
  • API vulnerability verification

Organizations need to have mechanisms and control for each of these steps.

The easiest and the first task to automate should be pushing verified security vulnerabilities into software lifecycle tools, Kulkarni said. "Once you have solid data on vulnerabilities, it makes sense to integrate that into not just software development tools but also in project management tools, CI/CD tools, ITSM tools, GRC tools, etc.," he said.

Organizations can also start with repurposing the output of other tools such as application scanning tools or their existing configuration management database to come up with an initial API inventory, Salt Stack's Isbitski said.

"They may find that they need more API context provided real-time, though, particularly as compliance teams, privacy officers, or regulators ask more questions about API endpoints, system integrations, sensitive data types, and data exchange."
—Michael Isbitski

Automatically collecting all relevant API metadata and maintaining an API inventory are common requirements for API security.

S&P Global's Kennedy said the key to modern API security is the automated discovery of APIs, typically by mirroring traffic from a load balancer or an API gateway. Most organizations are unaware of legacy or "rogue" API’s that might exist in their environment, resulting in a security gap. Once they have automated discovery of APIs, they need to have an automated way to discover APIs that interact with sensitive data so that risk mitigations and testing can be appropriately prioritized, Kennedy said.

4. Tap free tools where available

Isbitski said it's important for organizations to keep in mind the inherent limitations of static and dynamic analysis for API testing when seeking tooling options. "As a former practitioner and analyst, I frequently used and recommended OWASP Zed Attack Proxy (ZAP) as a free dynamic analysis tool," he said. He also recommends Portswigger Burp Suite as a good dynamic analysis tool that offers a free community edition, as well as low-cost commercial licensing.

Both ZAP and Portswigger Burp Suite are commonly used within the security practitioner community and by application-focused penetration testers, Isbitski said. In the realm of static analysis, there are many linters—or static tools—that are language-specific and can be partially useful for API testing, he said. "SonarQube is also a common free-to-low-cost option for static analysis," he added.

5. Be aware of the challenges of API security testing

Testing API security is different from testing the security of a web application, so it pays to be aware of the challenges.

API document and schema generation, for instance, is promoted as a best practice, said Isbitski. But the pressure to improve release velocity can sometimes cause application teams to forgo documentation or update schema definitions. This can result in a type of drift where real-world API deployment and its integrations bear little resemblance to what was initially defined or documented.

In addition, because organizations sometimes have a hard time getting all testing prerequisites in order, they end up limiting API testing to either static or dynamic analysis.

"This can result in test coverage gaps and potentially missing security issues, since each testing type has strengths and weaknesses."
—Michael Isbitski 

Tom Hickman, chief product officer at ThreatX, said that a failure to consider rogue and zombie APIs in the environment can lead to a gap between what the development team thinks is deployed and what is actually out there in the environment. "The long-standing tension between developers and security is exacerbated by the ease with which deprecated API endpoints can be left in production, exposed to both legitimate and malicious traffic," he said.

In big, highly distributed, horizontally scaled projects, it’s very easy for an API to slip into production after sound business logic testing, but without vulnerability scanning or static analysis, Hickman said. "This realization is shifting the dialog about API security toward the concept of API observability," he noted." Organizations want to see what traffic the endpoints are actually seeing, and the details of that traffic."

With growth, scale matters

Like any rapidly emerging development approach, APIs suffer from a lack of security awareness and immature tools, said Forrester's Carielli. Organizations need to be aware that API security tooling is incomplete and may not offer a full end-to-end set of API protections, she said.

To enable API security at scale, organizations should adopt the defense-in-depth approach. That means establishing a foundation of core application security practices, such as SAST, DAST, and SCA, Fortify's Thomas said. They then need to augment these practices with capabilities such as API discovery and anomaly detection.

Keep learning

Read more articles about: SecurityApplication Security