Threat-model the login system

Security work starts by asking what must be protected and how it could fail, not by adding a fashionable login library.

Protect credentials, sessions, private books, recovery channels, and administrative actions. Consider credential stuffing, enumeration, session theft, CSRF, XSS, insecure direct object references, reset-link theft, and compromised dependencies.

Draw the data flow before listing controls:

browser → application → session store
                    ↘ user database
                    ↘ email provider
                    ↘ identity provider

Every arrow crosses a trust boundary. Ask what data crosses it, who controls the input, and what evidence the receiver requires.

Write concrete abuse cases. “An attacker changes /books/17 to /books/18 and reads another user’s book” is testable. “Authorization might fail” is too vague.

Rank risks by likely impact and exposure. Credential stuffing on a public login deserves different controls from a malicious database administrator. Include recovery too: how will you revoke stolen sessions, rotate a provider secret, or notify affected users?

Do not assume one control solves a whole threat. HttpOnly reduces direct cookie theft through JavaScript, but it does not prevent actions made by injected code. Rate limiting slows guesses, but it does not make a reused password safe.

Create a table with asset, attacker goal, entry point, prevention, detection, and recovery. Include one unauthenticated attack and one signed-in user attacking another account.