What STRIDE helps you notice
STRIDE is a mnemonic for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. It helps a team look at a design systematically. It is a prompt for questions, not a scanner and not proof that a system is secure.
Imagine a course portal with a browser, an API, a database and a payment provider. A learner signs in, views lessons and pays a fee. Each component and connection is a place to ask what data moves, who can influence it and what happens if an assumption is wrong.
The six STRIDE questions
Apply these to each component and data flow:
- Spoofing: Could someone pretend to be a learner, staff member or service? Check authentication and account recovery.
- Tampering: Could a request, record or payment value be changed without permission? Check authorization, validation and integrity.
- Repudiation: Could an important action happen without a reliable record? Check audit events, timestamps and log protection.
- Information disclosure: Could private data reach someone who should not see it? Check access boundaries, encryption and data minimization.
- Denial of service: Could a user or integration exhaust capacity? Check rate limits, timeouts, quotas and recovery.
- Elevation of privilege: Could a low-privilege account or component gain broader access? Check role boundaries and service permissions.
A practical threat-modeling walkthrough
Keep the first model small enough to finish in a working session. Record assumptions so a teammate can challenge them.
Agree on scope
Name the feature, its users, its data and what a successful attack would mean. For example, protect learner accounts and paid lessons. Record what is out of scope.
Draw components and data flows
Sketch the browser, API, database, identity provider and payment service. Label important data on arrows, such as session tokens and payment status.
Mark trust boundaries
Show where control changes: an internet-facing API, third-party service, admin console or database network. Ask whether each component can trust what it receives.
Apply STRIDE
Ask the six questions at each boundary. Write concrete scenarios: 'a learner changes the lessonId in a request' is more useful than 'hackers attack the app.'
Prioritize and respond
Estimate likelihood and impact using a simple scale your team understands. Decide whether to mitigate, avoid, transfer or accept each risk; assign an owner to important actions.
Make mitigations testable
Turn controls into checks: verify server-side lesson authorization, test account recovery limits and confirm sensitive fields are not logged. Revisit the model after design changes.
Keep the model useful
A threat model gets stale when treated as a one-time document. Revisit it when you add a payment flow, administrator role, data store or external integration. A short review of a changed data flow beats a large diagram nobody maintains.
Focus on a few realistic scenarios, name the behavior that prevents them, and make the prevention testable. When an assumption needs specialist judgement, record it and ask for a security review rather than guessing.
Start with one feature and one diagram
Choose a feature you understand, draw its data flows and ask the STRIDE questions at every trust boundary. A small, maintained model helps a team make better design decisions before release.