Threat-model your login

Most security work starts in the wrong place — picking tools before anyone has written down what could actually go wrong. A threat model flips that: you list the ways an attacker could abuse a feature, then decide what to detect and what to fix. This episode runs one on a real login, end to end, in a few minutes.

We use an open-source lab app so you can follow along exactly. Clone it, or point the same command at your own project — the output is grounded in your code either way.

Before you start

• Node 18+ and a terminal.
• The lab app (optional, to follow along exactly):

git clone https://github.com/securenow-ai/lab-auth
cd lab-auth
npm install

You do not need a SecureNow account for this step. The threat model is a local, read-only audit.

Step 1 — Run the threat model

One command. Pick the security category you want to model — here, authentication:

npx securenow threat-model authentication

The agent reads your codebase, finds the routes, sessions, and password handling, and writes an exhaustive model for this app — never a generic checklist. Prefer a web flow? The same prompt is at securenow.ai/threat-modeling — copy it into your own coding agent (Claude Code, Cursor, Codex) opened at your project root.

Step 2 — Read what it found

It writes a two-track deliverable into threat/01-authentication/ — Markdown and a self-contained HTML page you can open in a browser:

• Code Findings — the audit. Each finding points at a real file:line, explains why it's exploitable, rates severity, and gives the exact fix (described, not applied).
• Detection & Mitigation — the runbook. Each modeled threat mapped to a detection you can run and a scoped mitigation.

For the lab's login it models dozens of threats — credential stuffing, password spraying, session fixation, token replay, host-header and forwarded-IP tricks, and more — and tells you which ones your code already defends against (the honest "strengths" list matters as much as the gaps).

Step 3 — Understand the shape of a finding

Every finding has the same anatomy, so it's easy to act on:

Threat     a specific abuse ("one IP tries many passwords across accounts")
Location   src/app.js:240 — POST /api/auth/login
Why        the concrete request an attacker sends, and what they get
Severity   critical | high | medium | low
Fix        the exact change, by pattern (not a blind code dump)
Detection  the runtime signal that catches it in production

That last line is the bridge to the rest of the series: a threat you can't fully prevent in code, you can still detect and contain at runtime.

Step 4 — Re-run it as the app grows

The model is cheap to regenerate. Run it again after every feature that touches auth — a new OAuth provider, a password-reset flow, an admin action — and diff the new findings against the last. The threat surface changes with every pull request; your model should too.

What you just did

You turned "is my login secure?" into a concrete, prioritized list grounded in your actual code — for free, without sending anything to a server. In Episode 2 we give the app eyes, so those detections have real traffic to watch.