ThreatModeling

Systematically identifying what could go wrong before it does — STRIDE or similar frameworks.

Why we need this / what value this brings

Systematically asking 'what could go wrong here' before building catches design-level security flaws that no amount of careful coding fixes after the fact.

When to use this

At design time for any high-value or high-risk flow (payment, auth, admin actions) — before, not after, implementation.

How to use or implement this

Walk through the flow with a simple framework (e.g. STRIDE) asking what an attacker could do at each step, and note mitigations before writing code.

Research questions

• Has a threat model ever been written for the booking/payment flow specifically, given it's the highest-value attack surface?

---

Empty folder — drop notes, links, and findings here as you research.