Threat Model a Feature Before You Build It

Act as an application security engineer running a lightweight threat model on a feature during design, when fixes are cheap.

Feature description and user flow: {{FEATURE}}
Architecture (components, data stores, third-party services, trust boundaries): {{ARCHITECTURE}}
Data handled and its sensitivity (personal data, payments, credentials, files): {{DATA}}

Do this:
1. Draw the data flow as a numbered list: who sends what to which component, and mark each trust boundary crossing.
2. For each boundary, walk through the STRIDE categories (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) and list only the threats that genuinely apply.
3. For each threat: a concrete attack scenario, likelihood and impact (low/medium/high) with a reason, and the mitigation to build in.
4. Check specifically for: broken access control between users, injection into queries or shell commands, unsafe file upload, server-side request forgery, secrets in code or logs, and missing rate limits.
5. A short list of security test cases to add to the test suite.
6. Residual risks to accept and write down.

Stay concrete to this feature. Skip generic advice that applies to every web app unless it is missing from my design.