StackHawk Expands API Security Testing Suite
StackHawk this week expanded the scope of its application programming interface (API) security testing tools to now include the entire layer.
Scott Gerlach, chief security officer for StackHawk, said the latest release of the Deeper API Security Test Coverage suite has been expanded to make it possible to now use realistic required variables for paths, query or request body.
The Deeper API Security Test Coverage suite is based on a dynamic application security testing (DAST) tool. This latest release also adds the ability to test scripts and data collected by tools such as Postman or Cypress to guide scanners by requiring access to API documentation.
Finally, StackHawk has added the ability to test specific use cases involving, for example, business logic, privacy laws and sensitive data that require custom scripts. This functionality also addresses the issue of tenancy checks and testing for broken function-level authorization.
The Deeper API Security Test Coverage suite is intended to enable cybersecurity teams to surface API issues in a way that makes it easier to share meaningful context with the application developers tasked with remediating those issues, said Gerlach.
Historically, the challenge cybersecurity teams have faced is that while they have tools to discover API vulnerabilities, the issues they surfaced can’t easily be recreated by developers. The Deeper API Security Test Coverage suite is specifically designed to make it simpler for developers to recreate the issue they are being asked to address, said Gerlach.
Over time, that ability to interact should significantly improve cybersecurity and application development teams’ ability to collaborate, he added. In fact, a new security engineer role is starting to emerge to help application development teams more proactively address security issues before and after applications are deployed, noted Gerlach.
In general, APIs are created by developers that often lack cybersecurity expertise. The probability mistakes will be made is high. The bulk of those APIs are not external-facing, but it’s worth noting that it’s not uncommon for an internal-facing API to suddenly become external as business conditions evolve. Unfortunately, not every API gets the same level of scrutiny before it is deployed so, as use cases evolve, a cybersecurity team may discover that an API lacks the appropriate level of security.
APIs, naturally, are only one element of any solid application security strategy. Many of the same issues that have plagued application security still apply. The challenge, of course, is that the number of APIs employed across a distributed computing environment is multiplying rapidly. Every modern application based on a microservices architecture makes use of multiple APIs to not only connect components but also integrate with other internal and external-facing applications. It’s now only a matter of time before cybercriminals start regularly scanning for API vulnerabilities to exploit.
It’s not clear how soon API security will become a crisis, but the potential is clearly there. Cybersecurity teams must get ahead of the issue today by putting in place API security testing processes that both developers and cybersecurity teams can embrace.