Thinking Like a Defender

What are we building, what can go wrong?

Threat modelling asks four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good job? Draw a data-flow diagram with trust boundaries (browser to server, server to database, service to third party), then consider threats at each crossing, for example using STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. Apply defence in depth and least privilege so a single failure does not become a breach.

STRIDE applied to a login endpoint

Example threats and mitigations.

Spoofing           stolen passwords used to log in       -> MFA, breached-password checks
Tampering          altered session cookie                 -> signed, server-side sessions
Repudiation        "I never changed that email"           -> audit log of account changes
Info disclosure    "user not found" vs "wrong password"   -> identical generic error messages
Denial of service  password-guessing floods               -> rate limiting, backoff
Elevation          role taken from a client-side field    -> roles only from server-side data

Threat model during design

A one-hour session before building a feature is far cheaper than fixing a design flaw after release.

Quick check: What does the S in STRIDE stand for?

• Storage
• Scanning
• Session
• Spoofing