Locking down the GraphQL endpoint

[chirino]

I noticed that the project has a GraphQL endpoint.

I'm a big fan of GraphQL for locked down aka (white listed queries). I'm not a fan of it for ad-hoc queries because It's typically easy to construct queries that can DOS your app. So do we have any strategies to mitigate this issue?

[JimFuller-RedHat]

The few problems I see with graphql are:

• putting graph facade/interface over 'rectangles' (eg. rdbms) ... this can lead to a long 'drip drip' of issues ... the problem gets a magnitude worst with mutations (eg. if one is doing graphql to perform db writes/updates)

• often consumers use graphql because it means less http invokes (often 1 instead of #n) ... the same challenges are still present (ex. pagination, scale, access control) ... in this sense there is little value in the 'graph' and the graphql endpoint is just being used as a bulk data exporter.

• An open ended graphql interface is far too broad/open ended and not as concise as a well designed (and small) REST API ... in larger, older, complex REST APIs people use graphql as a kind of vnext REST API to avoid complexity.

Ultimately a graphql interface over rdbms is tractable when it is usefully constrained otherwise I would prefer a graph interface over a graph database ... maybe someday ;)

[chirino]

graphql endpoint is just being used as a bulk data exporter.

I think that over-simplifies why it's used. It's effectively implementing a Frontend for Backend patten per page. This allows a frontend to data load everything needed to render a page with a single tailored response for the page. In cases where response time and bandwidth are important, graphql will win over standard REST apis.

But yes.. the hard part is security and robustness become harder to provide.

[JimFuller-RedHat]

I am talking more about 'data' and less about how any view of data is composited/aggregated downstream.

graph schema is open ended by design ... this is good when large parts of the world are unknown or contested (multiple truths) or federated or much richer in terms of metadata ... my point is that graphql usage (in the wild) often has very little to do with graph data (or querying graph) and more about generating a 'global var' for ux to use ...

FWIW using graphql as a kind of dynamic microservice generator means (for this programmer at least) it has all the negatives of using microservices which I am not a fan of.

I think there is a lot of good value in ensuring REST API are small and addresses primary use cases well. If we have good use cases defined for graphql lets do that well too.

[i386x]

that can DOS your app.

Hijacking the discussion. Recently I found this commit and I am a bit afraid if someone can upload hand-crafted SBOMs and then initiate delete operation with an intention to DOS application on the worst gc performance scenario? Based on theory, a (directed) graph with N nodes can have at most N*N edges so traversing such a graph-like data structure, like the one stored in Postgres database, may also require N*N operations. On the other hand the same number of operations can be probably needed when storing a sinister SBOMs to the database so my concerns are probably just a false alarm. What do you think?

[helio-frota]

Can we close this?

[ctron]

I think it's still a valid one.

[helio-frota]

I guess they don't have rate-limiter implemented yet
async-graphql/async-graphql#1618
https://docs.rs/async-graphql/latest/async_graphql/?search=limit

[helio-frota]

Created this issue #1228
(not saying that I'm going to do this -- right now)

[helio-frota]

So do we have any strategies to mitigate this issue?

The issue title includes "investigate." I don't want to imply that rate-limiting is the ideal solution, but we need alternatives for mitigation 👍

[helio-frota]

as a 'ping' I closed the issue and marked as invalid 👍