Catching coding errors in API preproduction, before they are spun up and go live is critical in preventing exploitable vulnerabilities. It’s why we’ve seen “shift left” become a significant focus in API development, whereby DevOps takes responsibility for incorporating security testing into the Software Development Life Cycle (SDLC), reducing the cost and expense of remediating coding errors and vulnerabilities.
But for developers who are not security experts, fixing code or knowing business logic abuse possibilities can be time-consuming, while security testers find it frustrating that code is not scrutinized enough. It’s for these reasons that automating testing is necessary, and adding generative artificial intelligence (AI) into the mix could also make it easier.
Automated API security testing predominantly uses tools from two application security methodologies: static application security testing (SAST) and dynamic application security testing (DAST).
SAST is used to detect vulnerabilities by analyzing the source code, and because of that, it tends to be used early in the development process. It integrates directly into API development environments like IDEs, bug-tracking systems, and continuous integration (CI)/continuous development (CD) tools. SAST works best when a standard specification enables it to detect common implementation issues in APIs like erroneously exposed APIs, parameters, error codes, and messages.
In contrast, DAST is a security testing method that sees a vulnerability scanner tool used to probe an actively running application in a production or non-production environment, but has no access to the source code. One of the essential requirements for a DAST for APIs is that the tool needs to understand the APIs, which includes both the syntactic and business logic it is exposing. A typical specification standard like OpenAPI Specification can help with the syntactic understanding of the API, but the business logic is much harder to understand. DAST looks to discover issues from the user/attacker angle and tends to be used in later stages of the development process.
Why API testing needs API tools
SAST and DAST are well-established web application tools that can be used for API testing.
However, the complex workflows associated with APIs can result in an incomplete analysis by SAST. At the same time, DAST cannot provide an accurate assessment of the vulnerability of an API without more context on how the API is expected to function correctly, nor can it interpret what constitutes a successful business logic attack. In addition, while security and AppSec teams are at ease with SAST and DAST, developers can find them challenging to use.
Consequently, we’ve seen API-specific test tooling gain ground, enabling things like continuous validation of API specifications. API security testing is increasingly being integrated into the API security offering, translating into much more efficient processes, such as automatically associating appropriate APIs with suitable test cases.
A major challenge with any application security test plan is generating test cases tailored explicitly for the apps being tested before release. In an API context, this might involve checking to see if the API is returning the correct data when called, an issue that if it goes wrong, could easily see application data being compromised.
API security testing poses a more complex problem because APIs are based on various technologies (GraphQL, REST, etc.), business functions (sensitive or non-sensitive data exposure), and other factors.
Many organizations create test plans manually, which can lead to errors and require developers to have knowledge of security test cases to associate with their APIs. API security testing adoption can be expedited by automating the manual associate test cases for API endpoints. This would enable application developers to identify the necessary security tests they need to perform before deploying the code from development to higher environments.
What role does generative artificial intelligence (GenAI) play here?
First, using plain English to create these test cases can shorten months to minutes. It can be used to automatically produce API security test plans and significantly reduce barriers to obtaining the results.
A security analyst might, for example, state, “Generate a test plan for my Payments API to ensure PCI data compliance” via an AI-enabled API security tool, avoiding the need to input the query or the detailed test plan. Such a test plan would then cue an automatic inspection of payment API endpoints and the payload characteristics and associate the appropriate test cases to test those endpoints for compliance with the PCI DSS.
In the event of a test failure, the remediation workflow can then be exported to third-party systems for remediation, with details into the cause provided by GenAI, and the test results can also be integrated into the CI/CD pipeline.
New test cases can be run outside the CI/CD pipeline against the production server for APIs already in production. It’s also possible to query those APIs against a specification to ensure estate-wide compliance with the preferred API specification or to run new test cases based on the OWASP API Top 10 2023 to ensure they are not susceptible to the tactics, techniques, and procedures exploits.
It’s still too early to determine the full impact that GenAI will have on API development and security testing. However, early evidence indicates that it has the power to reduce the time taken to generate test cases significantly and harmonize testing across development and security teams. Plain English prompting should make it much easier to query and gather the requisite information to demonstrate compliance with industry regulations. Crucially, it builds upon recent advances in integrating of API security testing within API security tools, meaning the sector no longer needs to rely purely on SAST/DAST tooling.