Example

This is a sample report for a made-up web shop, built from the Threat model example on the home page. Your own reports are made from your diagram, at /d/<id>/threat-report, and can be printed or saved as PDF. See how reports work.

Threat model Example

Web shop

Generated 22 Oct 2026 Diagram version example Modudraft
8
open threats
1 critical 7 high
50%
mitigated
11 of 22 threats
7components
7flows
5trust zones
1
unencrypted flows crossing zones

Risk overview

22 threats
Threats by severity
  • Critical 2
  • High 18
  • Medium 1
  • Low 1
Threats by status
  • Suggested 0
  • Open 8
  • Mitigated 11
  • Accepted 3
  • Not applicable 0

System

Internet DMZ Internal network (Internal) Restricted data (Restricted) Third-party HTTPS HTTPS Web app API gateway 2 Orders service 1 Users service 1 Invoice bucket Postgres 2 Stripe
Zones InternetDMZInternalRestrictedThird-party
Arrows Crosses zones unencrypted Crosses zones, encryption unknown Other
Badge 3Suggested or open threats

Top level only. On the app's canvas a badge's colour shows the highest severity.

Open the live example to explore it.

Trust zones

  • Internet

    1 component
    • BoundaryInternet
    • Web app

  • DMZ

    1 component
    • BoundaryDMZ
    • API gateway

  • Internal

    3 components
    • BoundaryInternal network
    • Orders service
    • Users service
    • Invoice bucket

  • Restricted

    1 component
    • BoundaryRestricted data
    • Postgres

  • Third-party

    1 component
    • BoundaryThird-party
    • Stripe

Data flows by class

Most sensitive class first

Payment

1 flow
FlowProtocolEncryptionZones
Orders service → Stripe HTTPS Encrypted Internal → Third-party

Credentials

1 flow
FlowProtocolEncryptionZones
API gateway → Users service Not set Unencrypted DMZ → Internal

PII

5 flows
FlowProtocolEncryptionZones
Web app → API gateway HTTPS Encrypted Internet → DMZ
API gateway → Orders service Not set Encrypted DMZ → Internal
Orders service → Postgres Not set Encrypted Internal → Restricted
Users service → Postgres Not set Encrypted Internal → Restricted
Orders service → Invoice bucket Not set Encrypted Internal

Data stores

StoreData classZoneAt rest
Invoice bucket PII Internal Encrypted at rest
Postgres PII Restricted Encrypted at rest

Threats

Most severe first
  1. #1

    Postgres may be open to injection through queries from Orders service and Users service

    Suggested (rule v1)
    TTampering Critical Mitigated
    Target
    Postgres
    Description
    If a query sent by Orders service and Users service is built from user input, an attacker can read or change any data in Postgres.
    Mitigation
    Both services use parameterised queries through the ORM.
    Owner
    Orders
  2. #2

    Postgres is reachable from outside the restricted zone

    Suggested (rule v1)
    EElevation of privilege Critical Open
    Target
    Postgres
    Description
    Postgres accepts connections from Orders service and Users service in another trust zone. A compromise in that zone gives a direct path to the database.
    Mitigation
    Allow connections to Postgres only from the services that need it, using network rules or security groups, and keep it off public networks.
    Owner
    Platform
  3. #3

    API gateway → Orders service carries PII without encryption

    Suggested (rule v1)
    IInformation disclosure High Mitigated
    Target
    API gateway → Orders service
    Description
    This flow crosses from the DMZ zone to the internal zone. Anyone on the network path can read it if it is not encrypted.
    Mitigation
    TLS 1.2 is now enforced between the gateway and Orders service, and the arrow is marked encrypted.
    Owner
    Platform
  4. #4

    Traffic from API gateway to Orders service can be altered in transit

    Suggested (rule v1)
    TTampering High Mitigated
    Target
    API gateway → Orders service
    Description
    This flow crosses from the DMZ zone to the internal zone. Without encryption and integrity checks, a network attacker can change requests or responses.
    Mitigation
    Requests to Orders service are signed by the gateway and checked on arrival.
    Owner
    Platform
  5. #5

    API gateway → Users service carries credentials without encryption

    Suggested (rule v1)
    IInformation disclosure High Open
    Target
    API gateway → Users service
    Description
    This flow crosses from the DMZ zone to the internal zone. Anyone on the network path can read it if it is not encrypted.
    Mitigation
    Require TLS 1.2 or later between API gateway and Users service, verify certificates, and mark the arrow encrypted once it is in place.
    Owner
    Identity
  6. #6

    Traffic from API gateway to Users service can be altered in transit

    Suggested (rule v1)
    TTampering High Open
    Target
    API gateway → Users service
    Description
    This flow crosses from the DMZ zone to the internal zone. Without encryption and integrity checks, a network attacker can change requests or responses.
    Mitigation
    Require TLS 1.2 or later between API gateway and Users service, and use mutual TLS or signed requests where the caller must be verified.
    Owner
    Identity
  7. #7

    Tokens in Web app can be stolen and replayed

    Suggested (rule v1)
    SSpoofing High Mitigated
    Target
    Web app
    Description
    A token taken from Web app, through an injected script or from device storage, lets an attacker act as the user against API gateway.
    Mitigation
    Session tokens live in HttpOnly, SameSite cookies, expire after 15 minutes and are revoked on logout.
    Owner
    Identity
  8. #8

    Requests from Web app to API gateway can be modified by the user

    Suggested (rule v1)
    TTampering High Mitigated
    Target
    Web app
    Description
    Anything running on a user's device can be changed, including prices, roles and hidden fields.
    Mitigation
    The gateway and services validate every request on the server, and order totals are recomputed on the server, never taken from the browser.
    Owner
    Orders
  9. #9

    API gateway may let unauthenticated requests through

    Suggested (rule v1)
    SSpoofing High Mitigated
    Target
    API gateway
    Description
    If API gateway does not check identity, every service behind it must authenticate requests itself, and one that forgets is open to anyone.
    Mitigation
    The gateway validates the JWT on every route except sign-in and forwards the verified user id to the services.
    Owner
    Platform
  10. #10

    API gateway has no rate limit set

    Suggested (rule v1)
    DDenial of service High Mitigated
    Target
    API gateway
    Description
    Without per-client limits, one caller can exhaust API gateway and the services behind it.
    Mitigation
    A global limit of 1,000 requests per second is set on the gateway.
    Owner
    Platform
  11. #11

    API gateway may forward traffic to Orders service and Users service without TLS

    Suggested (rule v1)
    IInformation disclosure High Open
    Target
    API gateway
    Description
    If TLS ends at API gateway, traffic behind it can be read or changed by anyone on the internal network.
    Mitigation
    Re-encrypt traffic from API gateway to Orders service and Users service with TLS, using mutual TLS where service identity matters, and mark those arrows encrypted.
    Owner
    Platform
  12. #12

    Orders service may accept calls from API gateway without authorization

    Suggested (rule v1)
    EElevation of privilege High Open
    Target
    Orders service
    Description
    If the service trusts any caller on the network, a compromised service can use it to reach data and actions it should not have.
    Mitigation
    Authenticate callers of Orders service with mutual TLS or signed service tokens, check what each caller is allowed to do, and run it with a least-privilege service account.
    Owner
    Orders
  13. #13

    Users service may accept calls from API gateway without authorization

    Suggested (rule v1)
    EElevation of privilege High Open
    Target
    Users service
    Description
    If the service trusts any caller on the network, a compromised service can use it to reach data and actions it should not have.
    Mitigation
    Authenticate callers of Users service with mutual TLS or signed service tokens, check what each caller is allowed to do, and run it with a least-privilege service account.
    Owner
    Identity
  14. #14

    Invoice bucket could expose objects through public access or listing

    Suggested (rule v1)
    IInformation disclosure High Mitigated
    Target
    Invoice bucket
    Description
    A misconfigured bucket policy or ACL lets anyone list and download every object in Invoice bucket.
    Mitigation
    The bucket policy denies public principals, and invoices are served through presigned URLs that expire after 15 minutes.
    Owner
    Orders
  15. #15

    Invoice bucket has no object versioning

    Suggested (rule v1)
    TTampering High Accepted
    Target
    Invoice bucket
    Description
    Objects that are overwritten or deleted, by mistake or by ransomware, cannot be recovered.
    Mitigation
    Invoices can be regenerated from the order record, so the cost of versioning is not justified.
    Owner
    Orders
  16. #16

    Postgres has no backups recorded

    Suggested (rule v1)
    DDenial of service High Mitigated
    Target
    Postgres
    Description
    Without tested backups, data lost to deletion, corruption or ransomware cannot be recovered.
    Mitigation
    Daily snapshots with point-in-time recovery, copied to a second region. The last restore test passed.
    Owner
    Platform
  17. #17

    Orders service and Users service may share credentials for Postgres

    Suggested (rule v1)
    SSpoofing High Open
    Target
    Postgres
    Description
    When several services use the same database login, one leaked credential exposes everything and the logs cannot tell the callers apart.
    Mitigation
    Give each of Orders service and Users service its own least-privilege database user, load the credentials from a secrets manager, and rotate them.
    Owner
    Platform
  18. #18

    Data from Stripe could be tampered with or malicious

    Suggested (rule v1)
    TTampering High Mitigated
    Target
    Stripe
    Description
    A compromised provider, SDK or network path can send responses or webhooks that your services trust.
    Mitigation
    Webhook signatures from Stripe are verified, and response bodies are validated against a schema.
    Owner
    Payments
  19. #19

    Kong does not slow sign-in attempts on the Users routes

    Suggested (agent)
    DDenial of service High Open
    Target
    API gateway
    Description
    Kong only limits routes that have the rate-limiting plugin attached. The global limit is high enough that credential stuffing against /users/sign-in is not slowed.
    Mitigation
    Attach the rate-limiting plugin to the Users service in Kong with a low per-IP and per-consumer limit on sign-in, backed by Redis so the count is shared between Kong nodes.
    Owner
    Identity
  20. #20

    S3 Block Public Access must stay on for the invoice bucket

    Suggested (agent)
    IInformation disclosure High Mitigated
    Target
    Invoice bucket
    Description
    A bucket policy can be changed to allow public reads. Only S3 Block Public Access at the account level stops that, whatever a policy says.
    Mitigation
    All four Block Public Access settings are on for the account and the bucket, enforced by a service control policy.
    Owner
    Platform
  21. #21

    Orders service sends payment data to third party Stripe

    Suggested (rule v1)
    IInformation disclosure Medium Accepted
    Target
    Orders service → Stripe
    Description
    Once payment data reaches Stripe, its storage, retention and access are outside your control.
    Mitigation
    A data processing agreement is in place with Stripe, and only a payment token and the amount are sent.
    Owner
    Payments
  22. #22

    This diagram has no logging or observability component

    Suggested (rule v1)
    RRepudiation Low Accepted
    Target
    Whole diagram
    Description
    No logging or monitoring component is drawn, so actions across these services leave no audit trail. Without one, nobody can show who accessed or changed data.
    Mitigation
    Services write audit logs to the cloud provider's log service for now. A dedicated observability component is planned for next quarter.
    Owner
    Platform