GraphQL has taken the engineering world by storm. The biggest names in engineering like Twitter and Lyft (and of course, Facebook) are using GraphQL as a simple, declarative way to retrieve data.
But if you are using GraphQL, then you know all that.
You also probably know that there aren’t a lot of security tools that are capable of running comprehensive tests against GraphQL APIs.
At StackHawk, we want to fix this. We know that API security is a code quality issue that teams across development and security are trying to tackle.
So we pioneered application security testing for GraphQL. And, we have released new updates to the StackHawk platform to give teams confidence that their GraphQL APIs are secure.
What are the latest updates? Check out all the details 👇
Better Application Coverage
One of the biggest struggles for users when it comes to scanning GraphQL is sufficient app coverage. We are tackling this in two new ways.
By default, StackHawk performs introspection against a GraphQL endpoint to identify base queries for the scanner to attack. For further coverage, users can pre-seed the scanner by providing a static GraphQL schema file in the StackHawk config.
In addition to pre-seeding the scanner, we have optimized how the scanner performs introspection to retrieve nested data leaks. In doing so, the scanner has access to a greater number of exploitable inputs and users reap the benefits of deeper application inspection.
We know that greater application coverage can come with longer scan times. We have also added progress details to the terminal output for long running GraphQL spiders so you can get a read on how much time is left on your scan. Additionally, if you use federated GraphQL, you can test each federated layer individually to reduce scan times.
Faster Scans and Less False Positives
By enabling two new config options in the StackHawk YAML, users can reap huge benefits in the form of faster scans with less false positives.
The first is the `app.autoPolicy` flag. When this flag is turned on, the scanner will pull an optimized scan policy, specific to GraphQL. With this in place, StackHawk pulls the correct tests to run for your GraphQL API, and ones that are irrelevant will automatically be skipped.
The second is the `app.autoInputVectors` flag. With this configuration option, the scanner will only send JSON requests to your GraphQL API. This means the API will be invoked correctly, less requests will have to be sent to effectively test for vulnerabilities, and malformed requests won't cause your scan to error out.
Fixing Faster, Built for Devs
Typically DAST scanners work by identifying vulnerabilities on a given route. This works well for web apps and can be helpful for other types of APIs, like REST or SOAP.
But since every query is sent to the same URL path in GraphQL, this approach doesn’t help teams effectively troubleshoot.
We have made huge platform improvements to surface findings information in a GraphQL friendly way.
When we find a vulnerability, the scanner does the work to inspect your schema and identify which exact query or mutation is causing the vulnerability.
These details are then surfaced in the StackHawk platform, showing the operation, operation name, and response/request information.
Like with other StackHawk findings, users can recreate the vulnerability with a cURL command in their IDE.
Start Scanning Your GraphQL API
Use these updates and get scanning!
We have tons of GraphQL specific docs to support you in delivering secure GraphQL backed applications, and we have a best-in-class support team made up of GraphQL whizzes.
If you are looking for more hands-on resources, make sure to register for our upcoming GraphQL AppSec learning lab, where we will walk through how to scan intentionally vulnerable GraphQL APIs, step by step.
