↑ arvau

MDN / Example threat model

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

  • Project: Blog website

  • Description: Public-facing blog serving static pages. Interactive components include user comments, a contact form, analytics scripts, and a map embed.

  • Version: 1.0

  • Last updated: 2026-04-13

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

1. What are we working on?

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:

  • Web browser and web platform

  • Operating system

  • Hosting provider infrastructure

Trust boundaries

This threat model assumes a trust boundary between:

  • The user’s browser and the server

  • First-party server components and third-party scripts

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

Components

IDComponentDescriptionC1Server with blog softwareReceives and processes requests, returning static pagesC2Authentication systemHandles user login and sessionsC3Comment systemStores and displays user-submitted contentC4Contact formAllows users to send emailsC5Third-party scriptsAnalytics and embedded map

Assets

IDAssetDescriptionA1User credentialsPasskeys and passwordsA2Session informationCookiesA3Personal dataEmail addresses, usernames, personally identifying information (PII)A4User-generated contentBlog commentsA5Draft contentUnpublished blog posts

Data flows

IDFlowDescriptionF1Authentication flowUser login and session establishmentF2Comment submissionUser submits content to serverF3Page renderingServer delivers HTML to browserF4Contact formMessage submission to administratorsF5Analytics flowTrack page viewsF6Map embedPage loads external data for interactive map

External dependencies

IDDependencyNotesE1Web browserAssumed to enforce the usual security mechanisms (e.g., same-origin policy) and no malicious WebExtensionsE2Hosting providerAssumed to provide safeguards, such as DDoS protectionE3Third-party scriptsLoaded from external origins

Stakeholders

IDStakeholderInterests / potential harmS1Anonymous usersPrivacy, security, content integrityS2Registered usersAccount safety, data protectionS3Disabled usersEqual accessS4Blog administratorsSystem integrity and availabilityS5Blog developerFixing flaws early onS6Business ownerProtecting brand reputation

2. What can go wrong?

Identified threats

IDThreatAffected elementsDescriptionT1Cross-site scripting (XSS)C3, A4, S1,Malicious comments inject JavaScript that run in other user’s browsersT2Account takeoverC2, A1, A2, A3, S2Stolen credentials or sessionsT3Spam and abuseC3, C4, S4Automated spamT4Data leakageA3, A5, S2Sensitive data exposed via misconfigurationT5Denial of serviceC1, S4, S5Excessive requests overwhelm server

3. What are we going to do about it?

Threat responses

ThreatResponse IDStrategyDescriptionT1R1ReduceSanitize user-generated contentT1R2ReduceApply a strict Content Security PolicyT1R3ReduceTemplate engine encodes outputT2R4ReduceImplement CSRF defensesT2R5ReduceUse Secure, HttpOnly, SameSite=Strict cookiesT2R6ReduceSession expires after 30-day idle timeoutT3R7ReduceApply rate limiting and spam filteringT3R8AcceptManual moderation of residual spamT4R9ReduceLimit data exposure and review logsT5R10ReduceApply request limits and timeouts

4. Did we do a good enough job?

Review status

  • All identified threats have at least one response.

  • No high-impact threats are currently unaddressed.

  • Residual risks (e.g., spam) are accepted with monitoring.

Follow-up actions

  • Revisit this threat model after:

    • Major feature changes

    • New third-party dependencies

    • Security incidents

    Review at least once per year.

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