Security vulnerabilities

### Summary

The password-reset endpoint at `https://admin.alwaysdata.com/password/lost/` appears to rely on the client-supplied `X-Forwarded-For` header when identifying clients for rate limiting.

After reaching the endpoint's request limit and receiving an HTTP `429 Too Many Requests` response, changing the `X-Forwarded-For` header value allowed additional password-reset requests.

During testing using my own email address, I received nearly 100 password-reset emails, demonstrating that the rate-limiting mechanism could be bypassed and that repeated email notifications could be triggered.

### Affected Endpoint

`POST https://admin.alwaysdata.com/password/lost/`

### Steps to Reproduce

1. Navigate to the password-reset page.

2. Submit password-reset requests using an email address you control.

3. Continue until the server responds with `HTTP/2 429 Too Many Requests`.

4. Change the `X-Forwarded-For` header value in the request.

5. Submit another request.

6. Observe that the endpoint accepts further requests despite the previous rate-limit response.

7. Check the controlled mailbox and observe the additional password-reset emails.

### Proof of Concept

Original request header:

`X-Forwarded-For: [initial value]`

After receiving HTTP 429, change the header:

`X-Forwarded-For: [different value]`

The endpoint then accepts further requests instead of consistently enforcing the rate limit.

### Impact

An unauthenticated attacker may be able to bypass the password-reset request limit by manipulating the `X-Forwarded-For` header.

This could allow repeated password-reset emails to be triggered for a target email address, potentially resulting in email flooding, user disruption, and abuse of the password-reset notification system.

Testing was performed only using an email address under my control.

### Recommended Remediation

- Do not trust arbitrary client-supplied `X-Forwarded-For` values.
- Configure trusted reverse proxies to overwrite or sanitise forwarding headers.
- Derive the rate-limit identity from the actual client IP as established by trusted infrastructure.
- Apply additional rate limits based on the destination email address and other appropriate identifiers.
- Consider a progressive cooldown and abuse-detection mechanism.

### Evidence

- HTTP 429 response showing that the rate limit was reached.
- Subsequent accepted requests after changing the forwarding header.
- Password-reset emails received in my controlled mailbox, with timestamps.