APIs are not only the backbone of modern application architecture, but they are also key when it comes to maintaining security. Typically, a company’s most valuable data all lives behind an API. Delivering secure applications is reliant 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
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 a real attack and surfaces vulnerabilities that have been 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 matches this against a database of known vulnerabilities. Using these tools, you would be alerted if your application or API is using a library or framework with a known vulnerability. With the ever increasing use of open source in API development, these tools are important 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 a lot of options out there. It can be difficult 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 important 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, but typically the preferred method is a tool that can automate testing in CI/CD and run locally for testing and debug. This allows a developer to be alerted quickly (on commit or PR) if they have introduced a new vulnerability, and quickly remediate that vulnerability 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 important 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 work in some cases, it often leads to missed API routes and does not work 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 all of the information it needs to fully test the API for security vulnerabilities.
API Types Supported: REST, GraphQL, and SOAP
Across an organization, it is common to encounter different APIs backing applications. It is not uncommon to have a company that has a combination of REST APIs, GraphQL, and SOAP APIs. When selecting a tool, it is important 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 highly important. 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 the 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 cuts 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 that you are selecting a developer-first security tool. 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 testing locally, and integrations with the existing engineering workflow.
API-First Application Security
Ensuring secure APIs is the only way to confidently deliver secure applications. And 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.
API-first development requires API-first application security testing.
This guide lays out evaluation criteria for selecting API security tools. Here at StackHawk, we’ve built the best-in-class tool for API security testing. You can test it for free by signing up for an account or schedule time with a product specialist if you’d like to learn more.
