Blog API — Where Authentication Stops and Authorization Begins

No way for a client to fetch its own profile (GET /auth/me)

POST /auth/login returns a user object at login time, but that's the only moment a client ever sees its own profile. If the token is loaded from storage later (page refresh, a different tab, a mobile app resuming from background) there is no endpoint to ask "who am I, according to this token?" without re-deriving it client-side from the JWT payload -- exactly the kind of trust-the-client shortcut this codebase's ownership model is built to avoid everywhere else.

PUT/DELETE on a nonexistent post or comment crashes with 500 instead of 404

Any client that tries to edit or delete a post/comment that's already gone -- because it was deleted moments ago in another tab, or the id was just typo'd or stale in a bookmark/cache -- gets a raw 500 Internal Server Error instead of a normal, expected 404. Every one of these also gets logged server-side via console.error, so this is also an on-call/logging problem: a completely routine, expected client mistake ("that post doesn't exist anymore") shows up in error monitoring looking exactly like a real server fault, drowning out signal that matters.

Replies can be nested more than one level deep

prisma/schema.prisma's Comment model is explicit about the intended design: "Stretch goal: optional self-relation for one level of threaded replies. A reply's parentCommentId must point at a comment on the SAME post; that cross-check is enforced in application code." The same-post cross-check is indeed enforced (POST /:id/comments rejects a parentCommentId from a different post). But nothing enforces the one level part: the handler only checks that the target parentCommentId exists and belongs to the same post -- it never checks whether that target is itself already a reply. Right now you can reply to a reply, then reply to that reply, indefinitely.

Duplicate email registration under load returns 500 instead of 409

Every account system eventually gets two signup requests for the same email arriving close enough together to race -- a double-submitted signup form, a flaky network causing a client to silently retry, two browser tabs. The sequential case ("register, then register again with the same email") already works correctly today and returns a clean 409. But the concurrent case -- both requests reaching the database before either has committed -- currently surfaces as a raw 500 Internal Server Error to whichever request loses the race. To a user that looks exactly like "the site crashed while I was signing up," not "you already have an account," which is a worse first impression and a guaranteed source of confused support requests precisely at the signup funnel's most sensitive moment.

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.