Example threat model

Note: This page shows an example threat model for a website. You are encouraged to copy it and change it to suit your own project. You can remove components your projects does not have, add different data flows, etc. Go through each of the four key questions and modify them as needed.

For more information and guidance on how to create a threat model, see the threat modeling guide.

Overview

Diagram showing components, assets, data flows, and trust boundaries for this example threat model.

1. What are we working on?

undefined

Assumptions and scope

This threat model covers the blog website itself, including user interaction and backend services.

Threats targeting the following layers are assumed to provide baseline protections, but are considered out of scope and not modeled here unless they directly affect this project:

Trust boundaries

This threat model assumes a trust boundary between:

Threats are most likely to occur where data crosses these boundaries.

Components

IDComponentDescription
C1Server with blog softwareReceives and processes requests, returning static pages
C2Authentication systemHandles user login and sessions
C3Comment systemStores and displays user-submitted content
C4Contact formAllows users to send emails
C5Third-party scriptsAnalytics and embedded map

Assets

IDAssetDescription
A1User credentialsPasskeys and passwords
A2Session informationCookies
A3Personal dataEmail addresses, usernames, personally identifying information (PII)
A4User-generated contentBlog comments
A5Draft contentUnpublished blog posts

Data flows

IDFlowDescription
F1Authentication flowUser login and session establishment
F2Comment submissionUser submits content to server
F3Page renderingServer delivers HTML to browser
F4Contact formMessage submission to administrators
F5Analytics flowTrack page views
F6Map embedPage loads external data for interactive map

External dependencies

IDDependencyNotes
E1Web browserAssumed to enforce the usual security mechanisms (e.g., same-origin policy) and no malicious WebExtensions
E2Hosting providerAssumed to provide safeguards, such as DDoS protection
E3Third-party scriptsLoaded from external origins

Stakeholders

IDStakeholderInterests / potential harm
S1Anonymous usersPrivacy, security, content integrity
S2Registered usersAccount safety, data protection
S3Disabled usersEqual access
S4Blog administratorsSystem integrity and availability
S5Blog developerFixing flaws early on
S6Business ownerProtecting brand reputation

2. What can go wrong?

undefined

Identified threats

IDThreatAffected elementsDescription
T1Cross-site scripting (XSS)C3, A4, S1,Malicious comments inject JavaScript that run in other user's browsers
T2Account takeoverC2, A1, A2, A3, S2Stolen credentials or sessions
T3Spam and abuseC3, C4, S4Automated spam
T4Data leakageA3, A5, S2Sensitive data exposed via misconfiguration
T5Denial of serviceC1, S4, S5Excessive requests overwhelm server

3. What are we going to do about it?

undefined

Threat responses

ThreatResponse IDStrategyDescription
T1R1ReduceSanitize user-generated content
T1R2ReduceApply a strict Content Security Policy
T1R3ReduceTemplate engine encodes output
T2R4ReduceImplement CSRF defenses
T2R5ReduceUse Secure, HttpOnly, SameSite=Strict cookies
T2R6ReduceSession expires after 30-day idle timeout
T3R7ReduceApply rate limiting and spam filtering
T3R8AcceptManual moderation of residual spam
T4R9ReduceLimit data exposure and review logs
T5R10ReduceApply request limits and timeouts

4. Did we do a good enough job?

undefined

Review status

Follow-up actions

Notes

This model is incomplete. Threat models continue to evolve as the site and security vulnerabilities continue to evolve. The purpose of a threat model is to improve shared understanding and guide security decisions, not to guarantee the absence of vulnerabilities.

See also