threat-modellisted

# Threat Model Ten minutes here removes the class of bug that no scanner catches, because missing authorization and absent rate limits are not patterns — they are omissions, and you cannot grep for something that was never written. Do this *before* the code exists. Retrofitting an authorization model onto a finished app is a rewrite. ## Ask, briefly You need four answers. Get them in one round of questions, not an interrogation: 1. **What is this and who uses it?** Single-user tool, multi-tenant SaaS, public site with accounts, internal dashboard? Multi-tenancy is the fork in the road — it means every query needs a tenant scope. 2. **What data does it hold?** Anything personal, financial, health, or credential-shaped? Anything that would be a bad headline? 3. **What is the stack?** Specifically the database and auth: Supabase, Firebase, Clerk, Auth0, NextAuth, custom. This determines where authorization actually lives. 4. **Who can reach it?** Public internet, or behind a VPN or SSO? If the user does not know yet, propose the safest default and move on. ## Then produce this — one page, no boilerplate **Assets.** What an attacker wants, ranked. Usually: user records, session tokens, the API keys in your env, the ability to send mail from your domain, and your metered API spend. Name the actual tables and services, not categories. **Entry points.** Every way data gets in: routes, forms, webhooks, uploads, third-party callbacks, and the database itself if