No rate limiting on login: unlimited brute-force attempts

POST /auth/login checks the submitted password against the stored bcrypt hash and returns 401 Unauthorized on a mismatch -- correctly, and without leaking whether the email itself exists. But there is no limit anywhere on how many times a client may attempt this for a given email. Nothing in src/middleware/ tracks attempts, so a single account can be probed with an arbitrarily long password list, as fast as the network allows, forever. bcrypt's hashing cost (config.bcryptSaltRounds) is the only thing slowing an attacker down at all, and it's slowing down legitimate logins by the exact same amount -- it was never meant to be the sole defense against brute force.

There is no rate-limiting building block anywhere in this codebase. requireAuth and requireOwnership are both stateless, answering their question from the request/DB alone every time -- nothing tracks failed login attempts per email across requests, so POST /auth/login will accept unlimited attempts for the same email forever.

cd nodejs/blog_api node_modules/.bin/jest --config practice-tickets/jest.config.js
practice-tickets/tests/ticket07_login_rate_limiting_missing.test.js --verbose

After 5 failed login attempts for the same email, the next attempt

returned 401 instead of 429.

This needs a genuinely new building block: nothing under src/middleware/ currently tracks any kind of per-request state across multiple requests (requireAuth and requireOwnership are both stateless, answering their question from the request/DB alone every time). A rate limiter has to keep a counter keyed by something derived from the request (here, the submitted email) and safely reset it after a time window -- and it has to do this correctly when requests for the same key arrive concurrently, or the limiter itself becomes another race to get wrong. src/lib/errors.js's Errors object doesn't have a 429 case yet either -- every existing status code it can produce is 400/401/403/404/409.

Two pieces, both new. First, a small middleware (e.g. src/middleware/rateLimiter.js) that, given a key-extraction function (here, req.body.email), tracks recent failed attempts per key and can answer "has this key exceeded the limit right now?" -- keep it in-memory, since this app has no other shared state store and a single-process in-memory counter is the right scope for this exercise. Second, wire it into POST /login in src/routes/auth.js: check the limiter before doing the bcrypt.compare work, record a failure when the password check fails, and clear that email's count on a successful login. You'll also want to add a TooManyRequests case to the Errors object in src/lib/errors.js, following the exact pattern the existing entries (Unauthorized, Forbidden, ...) already use.