Schematex
threatmodel·Microsoft STRIDE / Shostack (2014)·security, ecommerce·complexity 3/3·since v0.8.0

E-commerce checkout threat model (STRIDE)

A security data-flow diagram for a checkout flow with three trust boundaries. The engine applies the STRIDE-per-element mapping and flags every flow that crosses a trust boundary — where spoofing and tampering concentrate.

For the application-security engineer

Open in Playground →
threatmodel·§ —
↘ preview
100%
E-commerce checkout STRIDE threat model: 2 external entities, 2 process(es), 2 data store(s), 5 data flow(s). 3 boundary-crossing flow(s): Customer→1.0, 1.0→2.0, 2.0→Payment_Gateway. Customer (external) → Spoofing, Repudiation. Payment_Gateway (external) → Spoofing, Repudiation. 1.0 (process) → Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. 2.0 (process) → Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. D1 (store) → Tampering, Information disclosure, Denial of service. D2 (store) → Tampering, Repudiation, Information disclosure, Denial of service. E-commerce checkout Internet DMZ Internal HTTPS Checkout Place order Write order Charge card Order event Customer SR 1.0Web App STRIDE 2.0Order Service STRIDE Payment Gateway SR Orders DB TID Audit TRID
UTF-8 · LF · 15 lines · 436 chars✓ parsed·8.6 ms·9.8 KB SVG

What this shows

A STRIDE threat model of an e-commerce checkout drawn as a data-flow diagram (DFD): two external entities (the customer and a third-party payment gateway), two processes (the web app in the DMZ, the order service internally), and two data stores (the orders database and an audit log). Three trust boundaries partition the system — Internet, DMZ, Internal — and the labelled flows carry the data crossing between them.

The engine does the STRIDE-per-element analysis, not just the boxes. It applies the canonical mapping — externals get Spoofing/Repudiation, processes get the full S-T-R-I-D-E, stores get Tampering/Information-disclosure/DoS, and the audit log additionally gets Repudiation because it matches the log/journal pattern. Most usefully, it flags every flow that crosses a trust boundary — the customer→web-app HTTPS request (Internet→DMZ), the order-service→payment-gateway charge (Internal→Internet) — because boundary crossings are where spoofing, tampering, and information disclosure concentrate. Each element and flow carries its applicable STRIDE categories in data-*.

Threat model syntax →