Threat-model a feature

Threat-model this feature before it ships:

{{feature_description}}

Trust boundaries involved (who/what can send input, what's authenticated
vs not, what crosses a network boundary): {{trust_boundaries}}

Go through each of these, and only report a category if you actually find
something concrete - don't pad the list with generic advice that isn't
specific to this feature:
- Spoofing - can someone convincingly pretend to be a user or service
  they're not?
- Tampering - can input or stored data be modified in a way the system
  doesn't expect or validate against?
- Repudiation - can an action happen without enough of a trail to prove
  who did it, if that matters here?
- Information disclosure - does any response, log, or error message leak
  more than the caller should see?
- Denial of service - is there an unbounded or expensive operation a
  caller could trigger cheaply and repeatedly?
- Elevation of privilege - can a lower-privileged caller reach
  functionality meant for a higher-privileged one?

For each finding, rate it as low/medium/high based on both how easy it
would be to exploit and how bad the impact would be, and suggest the
smallest concrete mitigation - not "add more validation" but what,
specifically, to validate and how.

When to use

Before shipping a feature that accepts new input, crosses a new trust boundary (a new API endpoint, a new upload type, a new integration), or changes who can do what. Lightweight enough to run on a design doc before implementation, not just on finished code.

Why it works

STRIDE is a real, widely-used threat-modeling framework, and walking through it systematically catches categories (repudiation, denial of service) that a purely intuitive security review often skips in favor of the more obvious ones (injection, auth). Explicitly instructing “only report a category if you find something concrete” keeps the output actionable instead of a wall of generic security advice that would apply to any feature and gets ignored because of it.

Variations

• Add “This handles {{data classification, e.g. payment info, health data}}” if the feature touches regulated or especially sensitive data - it changes which findings should be treated as high severity.
• For an existing feature rather than a new one, add “Also note anything that was probably fine when this shipped but is riskier now given {{what changed since, e.g. it’s now public instead of internal-only}}.”
• Follow up with “Write this up as a short doc for the design review, ranked by severity” once you have the raw findings.