Skip to content

Expand default rate limit options #8489

Open
@dblythy

Description

@dblythy

New Feature / Enhancement Checklist

  • I am not disclosing a vulnerability.
    I am not just asking a question.
    I have searched through existing issues.

Current Limitation

Currently, there aren't any default rate limit options.

Feature / Enhancement Description

Endpoints such as request verification email should be covered by a default rate limit, such as 3 requests per hour.

Example Use Case

Alternatives / Workarounds

3rd Party References

Activity

parse-github-assistant

parse-github-assistant commented on Mar 30, 2023

@parse-github-assistant

Thanks for opening this issue!

  • 🎉 We are excited about your ideas for improvement!
added
type:featureNew feature or improvement of existing feature
on Apr 9, 2023
mtrezza

mtrezza commented on Apr 14, 2023

@mtrezza
Member

request verification email should be covered by a default rate limit, such as 3 requests per hour.

Well, these rate limits are highly suggestive. Rate limit is sort of the last line of defense, so I'd expect them to be generally higher. The difficulty is finding a spot between a likely malicious rate and a non-malicous rate that may occur in rare cases where users get confused or things don't work as expected.

As an example: for password reset I can imagine situations where a user requests 10 reset mails within 5 minutes. A well-designed client app would limit the re-requesting of password reset emails by displaying a countdown timer to the user of at least 30 secs. But we can't expect that app design when determining default values. Since the user is unknown we can only limit by IP. I think we can ignore the case of shared IPs (multiple users behind a NAT using a public WIFI access point) because a fairly popular app would not (and probably should not) use the Parse Server rateLimit option.

A more practical limit for password reset could arguably be around 60 - 120 req / hr / IP.

added
state:breakingBreaking change requires major version increment and `BREAKING CHANGE` commit message
on Apr 14, 2023
mtrezza

mtrezza commented on Jan 15, 2024

@mtrezza
Member

As rate limits are highly subjective, I could only imagine to enable rate limits for email-sending routes by default, if they are limiting per email address or user.

mtrezza

mtrezza commented on Feb 1, 2024

@mtrezza
Member

After some deliberation we decided that only rate limits for email-sending routes make sense, if limiting is per email address or user. Any other rate limiting would be app specific and too subjective to add as default. Since limiting per email address may be a different mechanism, I'm closing #8506 for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    state:breakingBreaking change requires major version increment and `BREAKING CHANGE` commit messagetype:featureNew feature or improvement of existing feature

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Participants

      @dblythy@mtrezza

      Issue actions

        Expand default rate limit options · Issue #8489 · parse-community/parse-server