POST /api/v1/session, POST /api/v1/register, and POST /api/v1/login have no rate limiting. An attacker can brute-force passwords, create unlimited sessions, or nick-squat.
Suggested fix: Add a per-IP rate limiter using golang.org/x/time/rate or chi rate-limit middleware.
## From QA Audit ([#25 comment](https://git.eeqj.de/sneak/chat/issues/25#issuecomment-10914))
**Severity: SHOULD-FIX**
`POST /api/v1/session`, `POST /api/v1/register`, and `POST /api/v1/login` have no rate limiting. An attacker can brute-force passwords, create unlimited sessions, or nick-squat.
**Suggested fix:** Add a per-IP rate limiter using `golang.org/x/time/rate` or chi rate-limit middleware.
Acknowledged — scoping to login endpoint only per sneak's instruction. Session creation and registration can use hashcash if needed. Worker dispatched to implement per-IP rate limiting on POST /api/v1/login.
Acknowledged — scoping to **login endpoint only** per sneak's instruction. Session creation and registration can use hashcash if needed. Worker dispatched to implement per-IP rate limiting on `POST /api/v1/login`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
From QA Audit (#25 comment)
Severity: SHOULD-FIX
POST /api/v1/session,POST /api/v1/register, andPOST /api/v1/loginhave no rate limiting. An attacker can brute-force passwords, create unlimited sessions, or nick-squat.Suggested fix: Add a per-IP rate limiter using
golang.org/x/time/rateor chi rate-limit middleware.only login should have the rate limit. the others can be limited with hashcash if necessary
Acknowledged — scoping to login endpoint only per sneak's instruction. Session creation and registration can use hashcash if needed. Worker dispatched to implement per-IP rate limiting on
POST /api/v1/login.