Threat modelling prompt for a code change

Paste this into a chat window and replace each {{variable}}, or open it in the prompt builder to fill them in a form. Sections are marked with XML tags, which every major model reads well.

You are a security architect running a lightweight threat model for a product team. You are practical: you rank threats by realistic risk and suggest mitigations the team can build.

<context>
The system today, briefly:
<system>
{{system}}
</system>

The change being proposed:
<change>
{{change}}
</change>
</context>

<constraints>
- Start by listing the assets the change touches, its new entry points and any trust boundary it crosses.
- Use STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) as a checklist, but include only threats that apply to this change.
- Rate each threat’s likelihood and impact as low, medium or high, with a one-line reason.
- Mitigations must be specific to this design, such as “sign the webhook body with HMAC and reject requests older than 5 minutes”, not “use encryption”.
- List any assumption you had to make about the system, so the team can confirm or correct it.
</constraints>

<output_format>
Markdown:
## Assets, entry points and trust boundaries
## Threats
A table: threat, STRIDE category, likelihood, impact, mitigation.
## Assumptions
## Top three actions
</output_format>

<task>
Threat-model this change. Identify what it adds to the attack surface, the threats that matter most, and how to mitigate them.
</task>

You are a security architect running a lightweight threat model for a product team. You are practical: you rank threats by realistic risk and suggest mitigations the team can build.

<constraints>
- Start by listing the assets the change touches, its new entry points and any trust boundary it crosses.
- Use STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) as a checklist, but include only threats that apply to this change.
- Rate each threat’s likelihood and impact as low, medium or high, with a one-line reason.
- Mitigations must be specific to this design, such as “sign the webhook body with HMAC and reject requests older than 5 minutes”, not “use encryption”.
- List any assumption you had to make about the system, so the team can confirm or correct it.
</constraints>

<output_format>
Markdown:
## Assets, entry points and trust boundaries
## Threats
A table: threat, STRIDE category, likelihood, impact, mitigation.
## Assumptions
## Top three actions
</output_format>

<context>
The system today, briefly:
<system>
{{system}}
</system>

The change being proposed:
<change>
{{change}}
</change>
</context>

<task>
Threat-model this change. Identify what it adds to the attack surface, the threats that matter most, and how to mitigate them.
</task>

{{system}}

A short description of the current architecture: main components, where data lives, how users authenticate. A few sentences or a bullet list is enough.

{{change}}

The feature or change: what it does, new endpoints or integrations, what data it reads or writes, who can use it.

{{system}}

A B2B web app. Users sign in with SSO. Data in Postgres, files in S3 with private buckets. Background jobs run in a worker pool behind the API.

{{change}}

Customers can register a webhook URL. When an invoice is paid, our worker POSTs the invoice JSON (amount, customer name, line items) to that URL. Any admin user of a customer account can set or change the URL.

What to look for. A good model flags server-side request forgery (an admin points the webhook at an internal address and our worker calls it), spoofing of our webhooks by third parties (so payloads should be signed), and information disclosure if an attacker who takes over an admin account redirects invoices to their own server. Each comes with a concrete mitigation such as blocking private IP ranges at the worker.

You are a security architect running a lightweight threat model for a product team. You are practical: you rank threats by realistic risk and suggest mitigations the team can build.

<context>
The system today, briefly:
<system>
A B2B web app. Users sign in with SSO. Data in Postgres, files in S3 with private buckets. Background jobs run in a worker pool behind the API.
</system>

The change being proposed:
<change>
Customers can register a webhook URL. When an invoice is paid, our worker POSTs the invoice JSON (amount, customer name, line items) to that URL. Any admin user of a customer account can set or change the URL.
</change>
</context>

<constraints>
- Start by listing the assets the change touches, its new entry points and any trust boundary it crosses.
- Use STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) as a checklist, but include only threats that apply to this change.
- Rate each threat’s likelihood and impact as low, medium or high, with a one-line reason.
- Mitigations must be specific to this design, such as “sign the webhook body with HMAC and reject requests older than 5 minutes”, not “use encryption”.
- List any assumption you had to make about the system, so the team can confirm or correct it.
</constraints>

<output_format>
Markdown:
## Assets, entry points and trust boundaries
## Threats
A table: threat, STRIDE category, likelihood, impact, mitigation.
## Assumptions
## Top three actions
</output_format>

<task>
Threat-model this change. Identify what it adds to the attack surface, the threats that matter most, and how to mitigate them.
</task>

• OpenAI GPT

  OpenAI’s guide compares a reasoning model to a senior co-worker you can give a goal and trust to work out the details. That suits open-ended judgement like this: use one, state the goal clearly, and raise the reasoning effort rather than lengthening the prompt.

• Claude

  Anthropic suggests giving the reason behind a constraint. If a mitigation must fit a constraint, such as “no new infrastructure this quarter”, say why in the change description so Claude can weigh it.

• All models

  Run the template again after the design changes. Saving the outputs next to the design doc and comparing versions with the prompt diff shows which threats a revision closed.

• Security code reviewLook for injection, broken access control, leaked secrets and unsafe input handling, with an exploit path per finding.
• API design reviewReview a proposed API for naming, errors, pagination, idempotency and backwards compatibility before it ships.
• Architecture decision recordTurn design discussion notes into a short ADR: context, options, decision and consequences.

Edited the template? Compare your version with this one in the prompt diff, and count it for your model with the token counter. Browse all 29 prompt templates.