Limiting Abuse Control (rate-limiting) to Client-Side Integrations

[eldadfux]

I'm thinking of limiting the abuse checks to client-side integrations only for all Appwrite different endpoints. I think it's becoming a bit limiting and counterproductive when using Appwrite with an API key.

We use rate-limiting today for mainly two scenarios. The first one is the protection of user authentication, and the second one is protecting write-heavy operations. Both cases are much more dangerous when we're talking about end-users access rather than just an internal server integration using an API key or upcoming JWT authentication methods.

I would love to get more community and team feedback about this before making any changes in the code.

[punitdiwan]

I think you can keep Abuse Control on Client Side and Server side as well, but keep it configurable using .env Variables with default values and document the same. It will make both client and server users happy.

[silentworks]

I think limiting it to client-side only is fine, but it would be good if the rate limit could be changed by the person setting up the Appwrite server. I don't like the idea of a hardcoded limiting set by the creators of the software themselves and not being configurable.

[eldadfux]

Do you think we should make this configurable at project or server level?

[kodumbeats]

Since most of Appwrite dev/user experience is handled at the project level, I think API rate limiting per project is appropriate.

[TorstenDittmann]

In my opinion, there should be no rate limit in conjunction with an API key.

API keys of this type are sensitive information and are usually treated as such, so there are completely different problems with a leaked key. Also, there are use cases in the server side - where a rate limit might actually compromise functionality.

The suggestion from @silentworks also sounds like a very good idea! 👍🏻

[eldadfux]

I 100% agree that this can actually compromise functionality on the server side.

[lohanidamodar]

I agree with @TorstenDittmann, Rate-Limit on requests with API keys doesn't make much sense. But in client side its a great security addition. But, yes it should be configurable, and best to have it configurable per project. As, different projects might have different requirement and sensitivity.

[stillie]

Apologies for the hijack, delete if need be, but i was wondering is rate limiting configurable? If so where? If not, is there plans to implement it?

[stnguyen90]

The only rate limit configuration is to enable/disable. See docs.

[stnguyen90]

It typically makes sense to only impose the abuse controls client side, but what about when Appwrite goes cloud/multi-tenant? What controls will be in place to prevent one org's project from using a server side api key to impact the performance of other projects and the entire server?

[eldadfux]

We have plans to handle this kind of miss-usage in multiple levels. Since this is sensitive security information about the Cloud service that could be used for abuse attempts, we better not disclose it publicly.

[brianmutiso]

I am here because I started using Appwrite yesterday, Appwrite is such a wonderful product,
Rate limiting on the client side can affect the developer, for example, right now I have to wait for 60 mins to continue development and testing, I think it should be configurable per project

[brianmutiso]

Does Rate limiting affect several devices on the same IP? for instance when an app is used by several people on the same public IP some will find it unusable, so allowing configuration per project might really help for such scenarios

[gewenyu99]

👋 We suggest disabling rate limiting during development. You can do this through changing the variable _APP_OPTIONS_ABUSE=disabled. Remember to enable it again once you're in a production environment!

https://appwrite.io/docs/environment-variables

[Shadowfita]

I completely agree with the idea of removing rate limits from the projects API key. I don't think it encourages large scale functionality by having that limit in place on a project level.

Limit users / client endpoints is a must though.

[brianmutiso]

Yes, i managed to disable it

…

On Wed, Apr 6, 2022, 6:27 PM Vincent (Wen Yu) Ge ***@***.***> wrote: 👋 We suggest disabling rate limiting during development. You can do this through changing the variable _APP_OPTIONS_ABUSE=disabled. Remember to enable it again once you're in a production environment! https://appwrite.io/docs/environment-variables — Reply to this email directly, view it on GitHub <#813 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQ3U3FQWBI6G3UEPFL6ZITVDWUPTANCNFSM4V4PMQDQ> . You are receiving this because you commented.Message ID: ***@***.***>

[ghost]

I think it should be configurable on both server and client too.

I've run into a problem where I can't use Appwrite since it is likely many people will create accounts at the same time.

[TorstenDittmann]

The rate limits for this also take the users IP into account. So the limits are not globally applied.

[ghost]

@TorstenDittmann

The user's local IP on their network? Or their network's public facing IP?

I should have mentioned that. It's likely there will be multiple accounts created at the same same time on the same network (like in a classroom)

[devberkay]

For example , i want to restrict usage of "Password Recovery" functionality of Account API to 2 requests maximum per 60 minutes but official documents says "This endpoint is limited to 10 requests in every 60 minutes per email address and IP address" , is it possible to make this happen?

[stnguyen90]

It's not configurable right now. You would have to modify this line before the appwrite container starts:

appwrite/app/controllers/api/account.php

Line 1851 in e3c9041

->label('abuse-limit', 10)

.

[stnguyen90]

As of Version 0.7.0, rate limits only apply to clients and are ignored when accessing Appwrite with an API key.