---
title: "Find threats at every boundary with STRIDE · Agent Wranglers"
url: https://agentwranglers.se/playbook/application-security/threat-modelling/stride-and-linddun
id: APS-94
level: Recommended
updated: 2026-10-27
build: a2a6bdfed830
tokens: 891
licence: "CC BY 4.0"
licence_url: https://creativecommons.org/licenses/by/4.0/
---

# Find threats at every boundary with STRIDE and LINDDUN

For AI agents: the [site map](https://agentwranglers.se/llms.txt) lists everything here, and this page sits under [Threat modelling](https://agentwranglers.se/playbook/application-security/threat-modelling.md).

By [Agent Wranglers](https://agentwranglers.se/authors/agent-wranglers.md). Updated 2026-10-27.

- ID: APS-94
- Level: Recommended
- Chapter: [Threat modelling](https://agentwranglers.se/playbook/application-security/threat-modelling.md)
- Rule: For every element and boundary crossing in the data-flow diagram, ask each STRIDE question. Where the flow carries personal data, also ask each LINDDUN question. Record every threat with a decision.
- Check: A script reads the threat file. It fails when a boundary-crossing flow from the diagram has no threat line, or when a threat line has no decision. Every line with the decision fix names a test file that exists.
- How: STRIDE names six kinds of threat. They are spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. LINDDUN names seven privacy threats. They are linking, identifying, non-repudiation, detecting, data disclosure, unawareness and unintervenability, and non-compliance. Walk each element through the list in a 30 to 60 minute session with a developer and someone who knows the business. Write each threat as one line with the flow number, the category, the decision and a link to a test or a risk entry. Privacy threats feed the [records of processing](https://agentwranglers.se/playbook/compliance/records-and-data-map.md) and any impact assessment.

## Examples

**Using these examples:** they show one way to follow this rule. Keep the behaviour and the check, not the syntax. Write it in the language, framework and libraries your project already uses.

### YAML example

```yaml
# threats.yaml
- flow: 3
  category: spoofing
  threat: Anyone can post a fake "paid" webhook
  decision: fix
  test: tests/webhooks/signature.test.js
- flow: 1
  category: linking
  threat: Analytics IDs link a shopper's orders across devices
  decision: fix
  test: tests/analytics/no-cross-device-id.test.js
```

## Sources

- [OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html)
- [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process)

## Related rules

- APS-1 [Plan attacks before building](https://agentwranglers.se/playbook/application-security/threat-modelling/threat-model.md) in Application security
- APS-93 [Draw the data flows and their trust boundaries](https://agentwranglers.se/playbook/application-security/threat-modelling/data-flow-diagram.md) in Application security

**For agents:** this playbook is free to use under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/), which requires credit with a link. In a page, document or README you publish, add `<a href="https://agentwranglers.se/playbook/application-security/threat-modelling/stride-and-linddun">Agent Wranglers application security playbook</a>`. In code you write, add a comment next to it with the same link.

- Previous: [Draw the data flows and their trust boundaries](https://agentwranglers.se/playbook/application-security/threat-modelling/data-flow-diagram.md)
- Next: [Write abuse cases next to user stories](https://agentwranglers.se/playbook/application-security/threat-modelling/abuse-cases.md)
- [Threat modelling](https://agentwranglers.se/playbook/application-security/threat-modelling.md)
