Feature Request: Rate limiting and Scoring

[ozum]

Would like to have rate limiting (# per user per second) and scoring of query cost (score per user per minute etc.).

Below points mentioned in https://blog.apollographql.com/securing-your-graphql-api-from-malicious-queries-16130a324a6b seems to nice to have in Hasura.

• Size Limiting
• Depth Limiting
• Query Cost Analysis

Kind Regards,

[kriswep]

I'd second this.

You could easily imagine malicious queries taking down APIs powered by Hasura. For example, running the following query against the todo learning API takes some time, and you could easily extend the nesting there:

{
  todos {
    user {
      todos {
        id
        user {
          id
          todos {
            id
          }
        }
      }
    }
  }
}

For the record, there was some discussion around this in #346, #989 and #1283 but they don't seem to have lead anywhere.

[coco98]

@kriswep Allowlists (#989) is ready for review and testing and should land soon. :) https://github.com/hasura/graphql-engine/pull/2075

The rest are fairly complicated and we're coming to it gradually!

[kriswep]

That's good to hear, haven't seen that before. But there are uses cases which query whitelisting doesn't fulfill (having a public facing API with unknown clients). Guess I hope other options like depth-limitng and costs analysis won't be forgetten.

[ozum]

The rest are fairly complicated and we're coming to it gradually!

I agree. Maybe starting with depth limiting would be easier and have relatively great impact on stopping malicious queries.

[ptrobert]

Wish List For rate limiting it will be good to have a per user per min/hour/ day/ month limits. A list of blocked users has to be maintained and ability to unblock them. Support for remote schemas as well

[mfdeux]

@ptrobert Short-term, most of those could be solved using the webhook auth method.

[txchen]

@mfdeux currently hasura is not forwarding the graphql query name/query details. If I want to do rate limit on insertions to a certain collection/table, how can we do it with webhook?

[mfdeux]

Ok, I understand. A short term hack I’m using is running through a proxy and parsing the query (using JS or Go), and then implementing rate limiting based on that, but obviously not a long term soution.

On Sat, Aug 3, 2019 at 21:25 Tianxiang Chen [email protected] wrote:

@mfdeux https://github.com/mfdeux currently hasura is not forwarding the graphql query name/query details. If I want to do rate limit on insertions to a certain collection/table, how can we do it with webhook?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hasura/graphql-engine/issues/2151?email_source=notifications&email_token=AEZLJ2I6FWS4YSGVCUVXGULQCYVYVA5CNFSM4HL2LKZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3PYTBI#issuecomment-517966213, or mute the thread https://github.com/notifications/unsubscribe-auth/AEZLJ2OFJZMKZFNSHTAE623QCYVYVANCNFSM4HL2LKZQ .

[txchen]

Yes, that can be a solution, but not very easy to use :) If hasura can forward more context info to webhook, and extend the protocol, I think rate limiting / recaptcha can be done easily.

[ptrobert]

opened a feature request for passing hasura query/mutation into webhook auth post body https://github.com/hasura/graphql-engine/issues/2666

[beepsoft]

I found this, it may provide some good ideas for complexity analysis:

https://github.com/slicknode/graphql-query-complexity

[ozum]

I found this, it may provide some good ideas for complexity analysis:

https://github.com/slicknode/graphql-query-complexity

@coco98, what @beepsoft posted could help.

[bitjson]

Has anyone tried to pass through the Postgres EXPLAIN "cost" estimate for this?

Even if it's off by orders of magnitude, being able to configure a HASURA_GRAPHQL_COST_LIMIT=100000 cap could prevent the most pathological queries for my use case.

[tsaiDavid]

This would be so valuable for us!

@dmi3y

[beepsoft]

@coco98 can you share your plans whether you will implement rate limiting in some form in the open source version of Hasura, or will it be a Hasura Pro option only (https://www.youtube.com/watch?v=JS6eMQ6H7eA)? Thanks!

[ozum]

@beepsoft, I didn't see that until I read your message.

Hasura is an open source engine that connects to your databases & microservices and flash instantly gives you a production-ready GraphQL API.

I hope Hasura is not becoming a "fake open source". It's understandable that offering paid services and paid support. However, splitting software features as an open source vs. pro seems to me not "open source". Worst of all, offering a fundamental feature such as rate limiting as a "pro" feature... Especially considering without rate limiting, a public facing graphql server is very vulnerable to attacks.

This is just my 2𝇍 as a developer, who publishes and contributes lots of open source projects.

[coco98]

Hi folks. We’ll always make sure you can run Hasura in production! Most of our time is and will be spent on open-source work.

Hasura Pro add-ons need Hasura (open-source) to have the required building blocks for rate-limiting (for eg: how allow lists work). We’ll be putting up the spec and raising the PR in a bit.

Also, I'm putting together a blogpost to answer how we will manage Hasura open-source soon too. :)

[beepsoft]

Hasura Pro add-ons need Hasura (open-source) to have the required building blocks for rate-limiting (for eg: how allow lists work). We’ll be putting up the spec and raising the PR in a bit.

@coco98 Does this mean that the open-source version of Hasura will definitely have some form of rate-limiting and this will be extended for the pro version?

[ozum]

Any progress on this?

[tspike]

Looks like they've added rate limiting as a Pro-only feature 😞

https://youtu.be/JS6eMQ6H7eA

[ozum]

From https://hasura.io/

Hasura is an open source engine that connects to your databases & microservices and flash instantly gives you a production-ready GraphQL API.

@coco98 said:

Most of our time is and will be spent on open-source work.

Also, I'm putting together a blogpost to answer how we will manage Hasura open-source soon too. ... We’ll be putting up the spec and raising the PR in a bit.

...and this:

https://youtu.be/JS6eMQ6H7eA

I agree with @tspike: 😞

[beepsoft]

Well, I got a thumb up from @coco98 for this question of mine, which means ... something.

@coco98 Does this mean that the open-source version of Hasura will definitely have some form of rate-limiting and this will be extended for the pro version?

[ozum]

@beepsoft I hoped as you thought. However this case has been open for a year and rate limiting seems already be available in "Pro" 🙄 version for months.

Hasura Pro add-ons need Hasura (open-source) to have the required building blocks for rate-limiting (for eg: how allow lists work).

I'm not trying to be rude, but IMHO this sentence does not mean open source version gets rate-limiting. I think, it means we are using open source version and all PRs as a base for our closed version.

[beepsoft]

@ozum I would really like this feature too and although I would not be too happy if it was only available in the Pro version, I would much appreciate a clean statement from Tanmai or someone from Hasua regarding its availability.

So, @coco98, @marionschleifer will we have rate limiting in the OS version or will it be a Pro only feature?

And as always: thank you very much for your efforts!

[pcmaffey]

I believe this issue https://github.com/hasura/graphql-engine/issues/2269 is the only thing blocking the ability to setup rate limiting via authhook. If Hasura enabled the ability for an authhook to set and pass headers back to the client in response, we could use session cookies to manage rate limiting manually.

[ozum]

@pcmaffey #2269 is also important FR. On the other hand rate limiting is not only limiting number of request. A malicious user can DoS every public hasura system with single query deep enough. (Only exception is white listing queries, which I think is a nuclear option)

[schettino]

Looking at the Pricing page, it suggests a lot of essential features are being cut from the OS version in favour of the "Pro" one - in special, rate limiting, which is a mandatory functionality for any production app. I feel that you're clearly moving towards a paid software, and a trend out there is to have another service/product that complements the main one in different ways (infrastructure, support, analytics, e.g. Cypress, Apollo, Prisma). Does this make sense?

I'd love to contribute monetarily, but I don't like the idea to being forced to do it.

Sorry if this is a harsh comment and I might be wrong about some points. In that case, I'd appreciate more transparency on some of the product plans, if that's possible.

Thanks =]

[ozum]

I even agree to be forced to pay if it does not label itself as "open source", because I would know from the beginning that I'm using a propriety software and there is a monetary agreement between me and developer. Otherwise, I could select an open source alternative.

In case of open source; People

1. Trust the developer,
2. Invest time to learn and implement the tool in their projects,
3. Contribute their time and skills free of charge as Pull Requests. (You can check my GitHUb profile to see my open source projects and contributions to others. I couldn't contribute to Hasura, because it is written a language I'm not an expert of.)

From home page of Hasura.com

Hasura is an open source engine that connects to your databases & microservices and auto-generates a production-ready GraphQL backend.

From pricing page of Hasura as @schettino pointed:

	Hasura Core	Hasura Pro
SECURITY
Session based rate limiting to prevent abuse/DoS attacks		✔

Hasura claims its open source offering production ready, but leaves it vulnerable to "abuse/DoS attacks" according to their own marketing page. (I also agree with them, it is vulnerable)

[mitar]

I am not sure what is so surprising? Somebody has to pay the bills. This is "open core" business model and for example GitLab is doing pretty well with it. And also their repository is full of issues asking for some feature to be moved to the community edition. It is simply a hard task to navigate this. So please give Hasura a bit of slack here.

Nobody is forcing you to use it. If you do not like it, move along. Open source means that you have freedom to use it, or change the code to suite your needs, not freedom to require others to adapt the code for you.

Or are people who are complaining here already spend hundreds of hours contributing to open source Hasura codebase and now they feel misused? I do not think so.

It is simply a reality that business models change, develop, and features come and go. This is even true for proprietary solutions. How many times it happens that a startup fails and says "in 1 week we are erasing all data". And you do not even have access to the code and cannot really do much.

So, let's move discussion about their pricing and business models somewhere else please, and let's keep this issue about how to get rate limiting (or hooks for rate limiting) to the open source version of Hasura. Nobody gains anything by people repeating a comment which is just glorified +1 on "free rate limiting". Who would not have free stuff. You do not have to comment to express that. Just upvote a comment or two you like about "me wanting free rate limiting" if you really want to express yourself.

[tombh]

Am I missing something? Is DDoS mitigation not best accomplished higher up the stack, nginx for example? Even fine-grained rate limiting can be achieved with nginx. Though of course I do concede that Hasura is best placed for managing recursive queries, etc.