Security work starts with two questions: what must we protect, and how could it fail? It does not start with picking a login library. The library comes later, once we know what we’re defending.

This exercise is called threat modeling. It sounds formal, but for the Books API it fits on one page.

What we protect

List the assets first. For us: credentials, sessions, private books, the recovery channels (email), and any administrative action.

Then list how each one gets attacked. The classic ones are credential stuffing, account enumeration, session theft, CSRF, XSS, changing an ID in the URL to read someone else’s data, stealing a reset link, and a compromised dependency. We’ll meet every one of these later in the course.

Draw the data flow

Before listing controls, draw where the data goes:

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

Every arrow crosses a trust boundary, a point where data moves from one party to another. For each arrow ask three things: what data crosses it, who controls that input, and what evidence does the receiver require before believing it?

Write abuse cases you can test

Vague threats produce vague defenses. “Authorization might fail” tells you nothing. Write it like this instead:

An attacker changes /books/17 to /books/18 and reads another user’s book.

That sentence is a test. You can write it as an integration test today and run it on every deploy.

Rank the risks

Not every threat deserves the same effort. Rank by likelihood and impact. Credential stuffing on a public login form is a daily event and needs controls from day one. A malicious database administrator is a different threat, handled differently.

Include recovery in the model. How do you revoke stolen sessions? How do you rotate a leaked provider secret? How do you tell affected users? If the answer is “we’d figure it out”, write it down now.

One control never solves a whole threat

Be careful with the idea that a single flag fixes a category of attack. HttpOnly stops JavaScript from reading the session cookie, but injected code can still send authenticated requests from the page. Rate limiting slows down guessing, but it does nothing for a password the user reused on a site that got breached.

Each control removes one piece of a threat. You stack them.

Try this now: make a table with six columns, asset, attacker goal, entry point, prevention, detection, recovery. Fill in at least two rows. One for an anonymous attacker hitting the login form, and one for a signed-in user attacking another account. The second row is the one most people forget.

Threat-model the login system