---
name: threat-model-your-app
description: Writes a short, evidence-based threat model for your own codebase - map components, trust boundaries, assets and entry points, list realistic abuse paths, rank them by likelihood and impact, and tie each fix to a place in the code. Use when the user asks for a threat model, wants to know how an attacker could abuse their app, or plans security work before launch.
license: Apache-2.0
metadata:
  category: backend
  tags: "security,architecture"
  author: johnny-bravo
  version: "1.0"
  updated: "2026-11-02"
  status: published
  aliases: "threat modelling, abuse cases, attack surface"
  source_url: "https://github.com/openai/skills/tree/49f948faa9258a0c61caceaf225e179651397431/skills/.curated/security-threat-model"
  source_license: Apache-2.0
  copyright: "Copyright (c) OpenAI (openai/skills, security-threat-model); Apache License 2.0 text in LICENSE.txt"
  original_author: "OpenAI (openai/skills, security-threat-model)"
  modified: "Modified by TheSkillVault on 2026-11-02: rewritten in plain English for small app owners, condensed to nine steps with an output outline; reference prompt templates not included; added gotchas and done-when. Not the original file."
  imported_on: "2026-11-02"
---

# Threat model your app

A threat model answers one question: who could misuse this, how, and what would it cost? Keep it short and tied to real code.

## When to use
- You are about to launch and want to know where the real risks are.
- A client, investor or review asks for a threat model.
- You added payments, uploads, admin tools or multi-tenant data.

## When not to use
- You want a hands-on scan for leaked keys and missing checks. Use audit-app-security, then use this to prioritise.

## Steps
1. Set the scope: which repo or folder, how it is deployed, and who can reach it from the internet.
2. List the parts that run: web app, API, workers, database, storage, third-party services. Only list what the code shows.
3. Draw the trust boundaries: browser to API, API to database, app to each outside service. Note auth and validation at each.
4. List the assets: user data, credentials and tokens, payment state, admin powers, compute budget.
5. List entry points: routes, forms, uploads, webhooks, cron jobs, admin pages.
6. Write 5 to 10 abuse paths as "attacker does X through Y to get Z", tied to an asset.
7. Rate each as low, medium or high for likelihood and impact, with one line of reasoning.
8. Ask the owner 1 to 3 questions that would change the ranking, such as "Is the admin page public?"
9. Recommend fixes tied to a location, such as "check order owner in `GET /orders/:id`". Mark which already exist.

## Output outline
- Scope and assumptions
- System summary and trust boundaries
- Assets and entry points
- Abuse paths table: path, asset, likelihood, impact, priority, fix
- Open questions

## Gotchas
- Generic lists ("use HTTPS") are not a threat model. Every row must point at this app.
- Separate runtime risks from build and CI risks; leaked CI secrets are their own row.
- Do not paste real secrets, customer data or private keys into the report.
- Do not overstate: note what an attacker cannot do, so priorities stay honest.

## Portability
Works with any language, framework or host. If you use a formal method like STRIDE, map each abuse path to its category; the steps stay the same.

## Example prompt
"Threat model my Next.js and Supabase app before launch. Rank the top risks and tell me where to fix each one."

## Done when
- Every entry point and trust boundary appears in at least one abuse path or is marked out of scope.
- Each high item has a fix pointing at a file, route or setting.
- Assumptions and open questions are written down.

---
Modified from "security-threat-model" in openai/skills (Apache-2.0). Changes by TheSkillVault are listed in the metadata above. See LICENSE.txt.