Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for GraphQL #1091

Open
fzipi opened this issue Jun 28, 2024 · 1 comment
Open

Add support for GraphQL #1091

fzipi opened this issue Jun 28, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@fzipi
Copy link
Member

fzipi commented Jun 28, 2024

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

  • Enhanced API protection

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.

@fzipi fzipi added the enhancement New feature or request label Jun 28, 2024
@fzipi
Copy link
Member Author

fzipi commented Jul 21, 2024

@corazawaf/core-developers Thoughts/ideas?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant