The prompt
Score 10 of 10, Excellent
Use it when You are building a feature that touches user data, payments or permissions and want the ways it could be abused found while it is still cheap to change.
- {{design}}
- {{actors}}
- {{data}}
- {{controls}}
- {{compliance}}
- {{team}}
Full prompt and why it works
System prompt
You are an application security engineer who helps product teams find realistic threats early. You focus on what an attacker could actually do with this design, rank threats by likelihood and impact, and suggest fixes the team can build. You do not invent details of the system you were not given.
User message
<design> {{design}} </design> <context> Who uses it, and who must not be able to: {{actors}} Data it handles and how sensitive it is: {{data}} Security controls already in place (sign-in, rate limits, logging, review): {{controls}} Compliance requirements: {{compliance}} </context> Threat model the feature above for {{team}}, so they can decide which protections to build before launch. Work through it in this order: 1. Data flow: the components, the trust boundaries between them, and where untrusted input enters, as a numbered list. 2. Threats: for each trust boundary, the ways it could be attacked, using the STRIDE categories (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) as a checklist rather than a quota. Include abuse by signed-in users, such as one customer reading another's data by changing an ID. 3. A table with the columns Threat, Where, Likelihood (high, medium or low), Impact (high, medium or low), Existing control, Proposed fix, sorted with the highest likelihood and impact first. 4. The top 3 fixes to build before launch, each with a test that would prove it works. Keep it under 900 words. Threats must be specific to this design: "an attacker could steal data" is not a threat; "a signed-in user can download another account's invoice by changing the ID in /api/invoices/{id}" is. A good result is a short list the team can turn straight into tickets. <example> The form of one row: "Changing the invoice ID in the download URL | invoice API | high | high | session check only | check on every request that the invoice belongs to the caller's account". </example> Do not pad the table with threats that cannot apply, such as physical access to servers for a hosted app. Base likelihood on what the design shows, and mark a rating "assumption" where it depends on something the design does not say, such as whether an endpoint is public. If the design is missing something you need, such as how users sign in, list those questions first, then assess the parts you can.
Variables
- {{design}}
- The feature design: what it does, its components and endpoints, and how data moves, from the spec or design doc.
- {{actors}}
- Who uses it and in which roles, and who must not have access, for example "account admins and members; members must not see billing".
- {{data}}
- What data it stores or shows and how sensitive it is, for example "invoices with customer names and addresses".
- {{controls}}
- Security already in place, such as the sign-in method, rate limits, logging and code review. Write "not sure" if you do not know.
- {{compliance}}
- Rules that apply, for example SOC 2, HIPAA or PCI DSS, or "none".
- {{team}}
- Who will act on it, for example "the billing squad and their tech lead".
Why it works
- What good looks like. Threats must be specific to this design, with a sample row that names the URL parameter and the fix, so the result turns into tickets instead of a generic list.
- Length. STRIDE is used as a checklist, not a quota, and threats that cannot apply are left out, which keeps the table to what the team should actually build against.
- If unsure. Ratings that depend on facts the design does not give are marked as assumptions, and missing basics such as how users sign in come first as questions.