fixes:
  - id: 1
    explanation: "Removing the setting to trust proxies does not improve security of the rate limiting. It might have some unforseen or unintended functional side-effects, though."
  - id: 2
    explanation: 'Replacing the "X-Forwarded-For" header with its standardized alternative "Forwarded" does not close the security flaw of how this header is actually being used and can be abused by attackers.'
  - id: 3
    explanation: "Reducing the rate limit from 100 requests in 5min to 10 reqests in 3min could be seen as a security improvement, if there wasn't an entirely unrelated misconfiguration at play here."
  - id: 4
    explanation: "Removing the custom key generator that lets an arbitrary HTTP header take precedence over the client IP is the best option here. Now an attacker at least needs to fake their actual IP to bypass the rate limiting, as this is the default key for the RateLimit module used here. There is a functional downside though, as now users behin e.g. corporate proxies might be rate limited as a group and not individually. But with 100 allowed password resets in 5min this should not occur too frequently."
hints:
  - "The security flaw has something to do with the rate limiting configuration."
  - "Do you think the time window or number of requests is the actual problem here? Maybe there is something else going wrong..."
  - 'Take a close look at the HTTP header being used here and ask yourself: "Could an attacker do anything with it to bypass rate limiting?"'
