In Java code review, "what could go wrong here" is ad hoc — you look for a
missing @PreAuthorize, a null check, a resource leak, and you find whatever
your own experience happens to remember to look for. STRIDE replaces that with a fixed
six-question checklist applied to a picture instead of the code: draw every
process, data store and data flow, then ask the same six questions of each one. A data
flow's questions even change depending on whether it crosses a trust boundary you actually
drew — a DFD with the zones different but no boundary line between them quietly
drops the one threat that boundary would have flagged.
Below is a three-element data-flow diagram: a browser posting a checkout request into a
process (checkout-svc), which writes into a store
(orders-db). STRIDE assigns a fixed set of categories per element
kind — a process gets all six, a store gets four, and a flow gets three plus a
fourth (Spoofing) only when it crosses a trust boundary that is actually declared on the
diagram. Pick an element below; the boundary checkbox controls whether the
internet↔app boundary between the browser and checkout-svc is drawn.
The zone of checkout-svc and orders-db is the same
(app) — that flow never gets Spoofing, boundary or not, because there is no
identity to forge crossing it. The browser's zone (internet) is different
from checkout-svc's — but a threat model that adds Spoofing to every flow whose
zones merely differ, without checking whether a boundary was actually drawn between those two
zones, over-counts on a diagram that names zones for documentation but hasn't drawn every
boundary yet. The exercise's threats(dfd) checks the drawn boundary list, not
just the zone names.