This means that whatever we provide, it should come from making variables available in the rule language, so they can be checked with simple "seclang" rules. Or we can follow a different approach. Let's see first what we want to protect users from.
Suggested protections from documentation
Limiting complexity:
Depth Limits: Use tools like graphql-depth-limit to specify the maximum depth of queries. For example, you might set a depth limit of 10 to prevent excessively nested queries.
Complexity Analysis: Calculate the complexity of each query by assigning scores to different operations. For instance, fetching a list of items might have a higher complexity score than fetching a single item. Tools like graphql-query-complexity can help automate this process.
Cost Analysis: Implement a cost analysis system to evaluate the resource consumption of each query. This involves assigning costs to different types of operations and rejecting queries that exceed a predefined cost threshold.
Introspection: if introspection is enabled, can we disable its use or we don't have all the information for this?
Batching Attacks. Can we prevent them?
Don't Return Excessive Errors. I think this can be done using a simple output rule. Will push this to the CRS community instead.
Let's hear your thoughts first on what should be prevented, then we can think the how.
Summary
While we have support for JSON, there is no explicit support for GraphQL as a content type we can parse.
I think there is enough interest in the community to bring protection to GraphQL, and Coraza should lead this.
References:
Motivation
Solutions
In this case the solution should focus more on defining first what we think protecting GraphQL means.
There is an existing graphql "armor" solution for nodejs, and this basically implements plugins with protections like https://escape.tech/graphql-armor/docs/category/plugins. Some of the plugins will apply in the request, but others apply at the response level.
This means that whatever we provide, it should come from making variables available in the rule language, so they can be checked with simple "seclang" rules. Or we can follow a different approach. Let's see first what we want to protect users from.
Suggested protections from documentation
Limiting complexity:
Depth Limits: Use tools like graphql-depth-limit to specify the maximum depth of queries. For example, you might set a depth limit of 10 to prevent excessively nested queries.
Complexity Analysis: Calculate the complexity of each query by assigning scores to different operations. For instance, fetching a list of items might have a higher complexity score than fetching a single item. Tools like graphql-query-complexity can help automate this process.
Cost Analysis: Implement a cost analysis system to evaluate the resource consumption of each query. This involves assigning costs to different types of operations and rejecting queries that exceed a predefined cost threshold.
Introspection: if introspection is enabled, can we disable its use or we don't have all the information for this?
Batching Attacks. Can we prevent them?
Don't Return Excessive Errors. I think this can be done using a simple output rule. Will push this to the CRS community instead.
Let's hear your thoughts first on what should be prevented, then we can think the how.