Add utilities for preventing malicious queries

[patrick91]

Some ideas here: https://www.apollographql.com/blog/graphql/security/securing-your-graphql-api-from-malicious-queries/

We can definitely implement some of those :)

• Depth limit
• Cost limit
• Introspection disable extension
• Extension to support persisted operations

Upvote & Fund

• We're using Polar.sh so you can upvote and help fund this issue.
• We receive the funding once the issue is completed & confirmed by you.
• Thank you in advance for helping prioritize & fund our backlog.

[jkimbo]

Because graphql-core is a direct port of graphql-js I think https://github.com/stems/graphql-depth-limit can be directly ported to Python.

[jkimbo]

@MeRuslan points out a another useful library to implement cost analysis: https://github.com/pa-bru/graphql-cost-analysis (ref: #902 (comment)). We could probably port that library to python as well.

Note that graphql-js has decided not to support adding directives through code definitions: graphql/graphql-js#1343

[jkimbo]

Another simple thing would be to add an extension that prevents introspection queries. That way you can add/enable it on production only to prevent people from introspecting your schema.

[Speedy1991]

Maybe this is also a thing to note:
https://www.apollographql.com/docs/react/api/link/persisted-queries/

Obviousy only useful for closed API's - it makes a gql scheme more "static" with the precalculated hashes

As far i know you can limit the server to only respond to known hashes

[jkimbo]

Maybe this is also a thing to note:
https://www.apollographql.com/docs/react/api/link/persisted-queries/

Persisted queries is the ultimate way to protect against malicious queries because it means you can’t execute a query that isn’t trusted. It’s very powerful but requires some effort with tooling to make it work well.

We should provide an extension that lets you implement persisted queries like envelop has: https://www.envelop.dev/plugins/use-persisted-operations

[erikwrede]

For reference from strawberry discord on cost calculation (will refine later)

Roadmap could be the following

M1: basic cost calc

• field costs
• defaults for
  • scalar field
  • list of scalars
  • other type (:1 relationship)
  • list of types (:m relationship)
• cost per list item
  • based on limit argument(projected cost exceeds the max cost)
• fitting design of schema directives (so we can do the eval in rust later and frontend clients can write codegens for that 😉 or apollo router plugin)

M2 advanced cost calc

• projected vs actual cost (limit of list vs actual list length)
• rate limiting (max x cost tokens per second per user via an extension)

M3 full integration

• dry run query to find out projected cost (no resolvers called) (see shopify api)
• cost headers in all web servers
  e.g.

x-actual-query-cost
x-tokens-remaining
or sth else

Example from stellate for reference:

query {
  # Total: 18
  todos(limit: 2) {
    # (Nested: 2 + 1 + 1 + 1 + (author: 2 + 1 + 1)) * limit: 2 = 18
    id # Scalar: 1
    text # Scalar: 1
    completed # Scalar: 1
    author {
      ## Nested: 4 (2 + 1 + 1)
      id ## Scalar: 1
      name ## Scalar: 1
    }
  }
}