As APIs have grown in use and abundance, so has the amount of attacks and breaches that stem from said APIs. The OWASP API Security Project and OWASP API Security Top 10 have helped to highlight the types of vulnerabilities that developers should be conscious of and defend against.
APIs are not only the backbone of modern application architecture, but they are also vital for maintaining security. Typically, a company’s most valuable and sensitive data all lives behind an API. Delivering secure applications relies on ensuring that the backing APIs do not have any security vulnerabilities.
Delivering secure APIs, however, is easier said than done. APIs sit at the intersection of teams and typically see rapid iteration as software is built and improved. Ensuring API security raises questions such as:
Which team is responsible for maintaining API security?
How do we ensure that updates to our APIs do not create a vulnerability?
Does our team have API security testing?
Modern software development teams are solving this problem with developer-centric API security testing automated in CI/CD. The rest of this post has more info on what API security testing is, how it works, and what to look for in selecting a vendor. Read on to learn more.
What is API Security Testing?
API security testing is the process of checking for vulnerabilities in your APIs, ultimately surfacing any potential security gaps for the engineering team to fix. Historically, this was done through penetration testing or manual scanning of the APIs by an enterprise security team. Currently, however, teams are shifting to running API security tests as part of the DevOps pipeline, ensuring that security issues are caught early in the development lifecycle.
Types of API Security Testing
The types of API security testing that could be performed are vast. Some are more manual, like API penetration testing, while others are more automated. When uncovering a potential API vulnerability, specific methods may be more applicable than others. For instance, if there are API security issues that only occur at runtime, then you'll need to have an API security testing tool that can assess the running application. Other vulnerabilities may be identified statically by running a static vulnerability scanner within the code base. With this in mind, let's take a look at a few types of API security testing tools.
Dynamic API Security Tests
While some static analysis security testing (SAST) and software composition analysis (SCA) tools have coverage for APIs, the best form of API security testing is running active (dynamic) tests against your API endpoints. This active testing is technically a form of dynamic application security testing (DAST), but beware of legacy DAST tools that are not built for APIs.
Running a dynamic API security test simulates an actual API-based attack and surfaces vulnerabilities introduced from both open-source dependencies and the code your team wrote. Of course, if you’re looking to build the most robust form of API security testing, combining dynamic testing with SAST and SCA would be ideal. But if you’re looking for the best first step to start securing your APIs, dynamic testing is the way to go.
Static API Security Tests
Static analysis security testing tools look at the source code of the application to identify potential vulnerabilities. This form of testing looks for patterns in the code that represent potential security concerns. These tools are language-dependent, meaning you have to use a static tool that matches the language your API is written in.
Software Composition Analysis
Software Composition Analysis (SCA) tools look at the dependency tree of your application and match this against a database of known vulnerabilities. Using these tools, you would be alerted if your application or API uses a library or framework with a known vulnerability. With the ever-increasing use of open source in API development, these tools are essential to include in security testing. The limitations of SCA tools are that (1) they generally do not surface if the vulnerability is actually exploitable within your API, and (2) they only capture open-source vulnerabilities, not security bugs your team may have introduced.
How API Security Testing Works
As outlined, there are various forms of API security tests. Static analysis and software composition analysis search for patterns and libraries in your code base that represent potential vulnerabilities, surfacing the vulnerable code or library. Dynamic API security tests send active requests to the application, surfacing potential vulnerabilities based on the response received from the API.
As an example, a dynamic testing tool may send a request to the REST API endpoint that includes SQL Injection. If a response is received from the API that indicates that the database is vulnerable to an attack, this would be surfaced in the testing tool.
Some people think of this form of security testing as negative security testing – a request is sent and if a response is received, it can represent a potential security bug.
What to Look for in API Security Testing Vendors
When evaluating tools to run security tests against your APIs, there are many options out there. It can be challenging to understand what tools are most effective for your particular team and use case. Below are some criteria that you can use to evaluate API security testing vendors:
Deployment Method: Does it Run in CI/CD?
One of the most essential aspects of API security testing is where the test will be run. This determines how close to the development process the testing will be. There are a few different ways that API security tests can be deployed. Still, typically, the preferred method is a tool that can automate testing in CI/CD and run locally for testing and debugging. This allows a developer to be alerted quickly (on commit or PR) if they have introduced a new vulnerability and quickly remediate it while still in the context of the code they are working on.
Other deployment methods include external scans of production or agents that run in staging. While these may be satisfactory for some organizations, most companies today see the value of testing in CI/CD.
Configuration: Explicit API Routes vs. Crawling for Discovery
Next, it is essential to understand how the tool finds the API routes for testing. Legacy tooling on the market relies on an HTML spider of the application to surface API routes. While this may sometimes work, it often leads to missed API routes and is not ideal for use with single-page applications.
Other legacy tools attempt to find API routes by proxying production traffic or relying on functional tests written in QA. For example, WhiteHat’s new API testing tool, Intelligence Directed DAST, only runs security tests on the API routes that have custom tests built in Postman.
Modern tooling is configured directly for API scanning, leveraging technologies such as OpenAPI Specification or the GraphQL introspection end point. This gives the security tool the information it needs to test the API for security vulnerabilities thoroughly.
API Types Supported: REST, GraphQL, gRPC, and SOAP
Across an organization, it is expected to encounter different APIs backing applications. It is not uncommon to have a company where their API landscape combines REST APIs, GraphQL, gRPC, and SOAP APIs. When selecting a tool, it is crucial to ensure that it supports the types of APIs you use internally right now, as well as those that you may use in the future.
Performance: Data-Driven Nodes
When running API security tests, especially when run in CI/CD, performance is critical. Security testing of APIs should add seconds or minutes to the build pipeline, not hours like many traditional tools.
One key functionality for performance is testing the underlying API route vs. every iteration of this route. This functionality is known as Data Driven Nodes. For example, if an online clothing retailer has an API path such as /pants/{pantsBrand}/list. Many traditional tools will iterate through testing of every variation of {pantsBrand}, which adds significant inefficient time into scans. Modern tools should understand Data Driven Nodes and only test the underlying route.
Scan Quality: Technology-Specific Scanning
Many tools in the API and application security space run the same tests, regardless of what API you are using. Be sure to select a vendor or tool that has technology-specific scanning. REST and GraphQL APIs should only receive JSON-based requests, and SOAP APIs should receive XML-based requests.
Technology-specific scanning results in several benefits for teams running API security tests. When a testing tool is sending the right kind of requests to an API, scans are both fast and accurate.
Accuracy: Minimize False Positives
When it comes to security tests, accuracy is obviously important. False positives create unnecessary work for engineering and security teams, ultimately eroding trust in security testing. Many companies have started down a path of security testing, only to abandon the tool due to a poor signal-to-noise ratio from so many false positives.
When selecting a vendor, it is essential to ensure that your security testing vendor is built for modern application architecture and API security testing. This often looks like automatic recognition of whether the tool is testing an API or HTML application and applying the correct tests for each path.
Custom Testing: Find Business Logic Vulnerabilities
Some vulnerabilities cannot be tested for using automatic tools. Custom business logic or certain application-specific features will require custom security testing. The ideal API security testing vendor will enable this sort of testing and tie results in with the out-of-the-box testing.
Developer Experience: Developer-First API Security
With automated API security testing in CI/CD, developers are inherently brought into the security process. Application security has shifted left – scheduled scans of production and a team of security analysts reviewing the results no longer cut it. Today’s engineering teams run security tests in CI/CD, alerting the developer who was working on the code if they’ve introduced a new vulnerability.
When selecting a vendor, ensure you select a developer-first security tool that is easy for developers to use and integrate with their existing flow. For API security testing, this includes features such as cURL command generation to recreate findings, simple CI/CD automation, config as code, the ability to run tests locally, and integrations with the existing engineering workflow.
API-First Application Security
Since virtually every application is built on top of APIs, ensuring that APIs are secure is the only way to deliver secure applications confidently. While application security is critically important for any business today, many application security tools on the market today were built for a previous era of software development. By combining the latest application security testing tools with other cutting-edge API technologies, such as an API gateway or API management tool, you can guarantee a much higher level of security within your APIs.
Another critical point is that API-first development requires API-first application security testing. Since in the API-first approach, APIs are generally built first and then integrated with further parts of the application; this requires tools that can test APIs as they are being built. Two great ways to do this, as pointed out earlier in this article, are to use DAST and SAST to scan and test the APIs to ensure they are ready for integration.
In this guide, we looked at some evaluation criteria for selecting API security tools. Here at StackHawk, we’ve built the best-in-class tool for API security testing that offers a best-in-class experience for implementing a DAST solution. To get started with StackHawk, you can test it for free by signing up for an account or scheduling time to chat with our team of API security experts if you’d like to learn more.
