Security
What a threat model looks like for a small web app
By Zettops. Published · 4 min read
A threat model is not a binder for banks. For a small web app it fits on one page and shapes almost every decision that follows.
Threat modeling has a reputation for being heavy, formal, and only for large companies. For a small web app it is a short, plain document that answers one question: how could this go wrong, and what are we doing about it?
What a threat model is, and what it is not
A threat model is a shared picture of your system, the things in it worth protecting, and the ways someone could misuse it. It is written before the build and updated as the product changes.
It is not a penetration test, a compliance certificate, or a list of every possible attack. The goal is to find the risks that matter for this product and make deliberate decisions about them, instead of discovering them in production.
For a small app, one page is often enough. We start every project with one, because it is far cheaper to move a box on a diagram than to move a database after launch.
Step 1: Draw the system
Sketch the pieces and the lines between them. Keep it rough.
- Who uses it: visitors, signed-in users, admins, and any automated clients.
- What runs where: the browser, your API, background jobs, the database, file storage.
- What you depend on: payment providers, email services, analytics, AI models, third-party APIs.
- Trust boundaries: every place where data crosses from something you control to something you do not, such as the browser to your API, or your API to a vendor.
The trust boundaries are where most problems live. Mark them clearly.
Step 2: List what is worth protecting
Write down the assets, in plain words:
- User accounts and sessions
- Personal data: names, emails, addresses, anything regulated in your market
- Payment details, or the tokens that stand in for them
- Admin access and the ability to change content or settings
- API keys and secrets for the services you depend on
- Availability: the app being up when people need it
If you cannot name what you are protecting, you cannot judge which risks are serious.
Step 3: Ask how each piece could fail
A simple way to structure this is STRIDE, a long-standing checklist of six threat types. Walk each part of your diagram through it.
| Threat | The question to ask | A typical answer for a small app |
|---|---|---|
| Spoofing | Can someone pretend to be another user or service? | Strong session handling, multi-factor auth for admins |
| Tampering | Can someone change data they should not? | Server-side validation, authorization checks on every write |
| Repudiation | Could someone deny an action we cannot prove? | Audit logs for admin and payment actions |
| Information disclosure | Can data leak to the wrong person? | Access checks per record, no secrets in client code |
| Denial of service | Can someone make it unusable? | Rate limits on login, forms, and expensive endpoints |
| Elevation of privilege | Can a user gain admin powers? | Roles checked on the server, never trusted from the client |
You will not hit every row for every component. That is fine. The point is to ask the question on purpose.
Tip: the most common gap we look for is an endpoint that checks whether a user is signed in, but not whether this record belongs to them.
Step 4: Decide, then write it down
For each risk you find, pick one of four responses:
- Fix it: change the design or add a control.
- Reduce it: add a limit, a log, or an alert that makes it smaller or easier to spot.
- Accept it: the risk is small or unlikely, and you say so explicitly.
- Transfer it: let a specialist provider handle it, such as card data with a payment processor.
Record the decision next to the risk, with an owner. A risk you accepted on purpose is very different from one nobody noticed.
Keep it alive
A threat model goes stale the moment the product changes. Revisit it when you:
- add a new kind of user or role
- connect a new third-party service or AI model
- start storing a new type of data
- open a new public endpoint
Keep it short enough that updating it takes minutes. Pair it with the habits that keep it true day to day, which we cover in least privilege in practice.
Where to start
Take your current app, draw it on one page, and run each piece through the table above. If you would like a second pair of eyes on the result, a threat model and security review is how our secure backend engineering work usually begins, or you can get in touch directly.