Editorial illustration; the dashboard does not show a real site or incident.
Published on October 19, 2026.
Most small websites do not need a forty-page security document. They do need a few minutes of honest thinking before a problem arrives.
If you run a portfolio, blog, small shop, membership site or internal tool, ask yourself: what would hurt most if it were exposed, changed, deleted or made unavailable? The answer is more useful than a long list of scary attack names. It tells you where to spend limited time and money.
Quick Answer
A simple threat model can be done in four passes:
- List the assets and actions worth protecting.
- Draw the basic path data takes through the site.
- Imagine realistic ways that path could fail or be abused.
- Choose a small control, owner and test for each important risk.
OWASP describes threat modelling with four similar questions: what are we working on, what can go wrong, what will we do about it, and did we do a good enough job? You do not need to use a complicated framework to benefit from that sequence.
Why a small website still needs a threat model
“Small” does not mean “uninteresting”. A site may contain customer names, email addresses, invoices, unpublished posts, administrator accounts, payment links or the reputation of a local business. A simple blog may also be connected to a domain account, email account, deployment service and analytics dashboard.
The biggest risk is often not a movie-style intrusion. It may be a leaked password, an accidentally public storage bucket, an editor account with too much access, a plugin that is no longer maintained, or a backup that cannot be restored. These are ordinary failures, which is exactly why they deserve a practical response.
Step 1: Write down what you are protecting
Start with a small inventory. Do not begin with “What attacks exist?” Begin with “What would I regret losing or exposing?”
Create a table with four columns:
| Asset | Why it matters | Where it lives | Who needs access |
|---|---|---|---|
| Customer contact list | Privacy and trust | Database or CRM | Owner and support |
| Published content | Reputation and continuity | CMS and backup | Editors |
| Domain account | Controls the public address | Registrar | Owner only |
| Deployment token | Can change the live site | CI/CD settings | Build system |
Include actions, not just files. “Publish an article”, “refund an order” and “invite an editor” are all security-relevant actions. A person who can perform an action may have more power than a person who can merely read a record.
Give each item a rough priority: high, medium or low. High does not mean it will definitely be attacked. It means a failure would have a serious effect and deserves attention first.
Step 2: Draw the smallest useful data flow
You do not need a polished diagram. Put a few boxes on paper or in a note:
Visitor -> Browser -> CDN or web server -> Application -> Database
|
-> Email, payment or analytics provider
Add the people and services that can change the system: you, another editor, the hosting dashboard, the repository and the deployment pipeline. Mark the boundaries where trust changes. A visitor is not the same as an authenticated editor. A third-party email provider is not the same as your database. A build job should not automatically receive every secret in the account.
This step exposes assumptions. Perhaps the contact form sends email directly from the web server. Perhaps the database is reachable from the public internet even though it only needs to talk to the application. Perhaps a preview deployment receives production credentials by mistake. You are not trying to prove the diagram is perfect. You are trying to make invisible connections discussable.
Step 3: Ask what could go wrong at each boundary
For each box and connection, write a few concrete questions:
- Can someone pretend to be an administrator?
- Can an ordinary user read or change another user’s record?
- Can a visitor submit unlimited expensive requests?
- Can sensitive data travel or be stored without appropriate protection?
- Can an editor deny having made a damaging change because no useful audit trail exists?
- Can an attacker gain more permission than the account should have?
These prompts resemble the STRIDE categories used in software threat modelling: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. You do not need to label every possibility with an acronym. Use the categories as a reminder to consider identity, integrity, accountability, confidentiality, availability and privilege.
Keep the threats specific. “Hackers attack the website” is too vague to guide a decision. “A stolen editor password is used to publish a fake payment notice” gives you a scenario, an asset and a likely control. “A public form is submitted repeatedly until the email provider blocks the account” suggests rate limiting and monitoring.
Step 4: Rank risks by impact and plausibility
Use a simple two-question test:
- If this happens, how bad is the result?
- How believable is the path to it?
You can score each from one to three, but do not pretend the result is mathematical truth. The purpose is to decide what to work on first.
For example, losing a draft blog post may be inconvenient, while losing control of the domain may interrupt the whole business. A brute-force attack against a well-protected admin page might be less urgent than an old shared password used for the registrar. A risk that is both damaging and easy to reach deserves a near-term action.
Write down assumptions too. Maybe you assume the payment provider handles card data, the hosting platform patches its operating system, or only two people can access production. An assumption is not a control. Confirm it, assign someone to check it, or record the remaining uncertainty.
Step 5: Choose controls that match the scenario
Good controls are specific and testable. For the stolen editor password scenario, possible actions include a password manager, unique credentials, phishing-resistant multifactor authentication where available, least-privilege roles and an alert for unusual publishing activity. CISA recommends MFA as an additional layer because a compromised password alone should not be enough to access an account.
For accidental exposure, use private-by-default storage, review sharing permissions and remove secrets from content and logs. For tampering, use code review, protected branches, deployment approvals and a rollback path. For data loss, make backups and perform a restore test. For abuse of a public form, add input validation, rate limits, bot controls and monitoring appropriate to the endpoint.
Do not install a security product just to make the document look complete. A control that nobody maintains is a future false sense of safety. Prefer a short list with an owner and a date:
| Risk | Control | Owner | Test |
|---|---|---|---|
| Stolen admin password | MFA and unique password | Site owner | Sign in using recovery plan |
| Bad deployment | Review and rollback | Developer | Deploy a harmless change |
| Deleted customer data | Backup and restore procedure | Operator | Restore to a separate environment |
Step 6: Test the uncomfortable parts
A written promise is not evidence. Try the recovery account. Confirm that an editor cannot open the billing dashboard. Check that a deleted page can be restored. Search the repository for accidentally committed keys, then rotate any real secret that was exposed. Review who can access the domain registrar and hosting account.
Keep tests safe: use a staging site or a copy of data when possible. The aim is to learn whether the control works, not to create an outage. Record what failed and turn the result into a small improvement.
Common mistakes to avoid
Do not copy an enterprise threat model into a two-person project without changing its assumptions. Do not list every theoretical attack while ignoring a reused password. Do not treat HTTPS as proof that a site is trustworthy; HTTPS protects the connection to a domain, not the honesty of the person operating that domain. Do not give every contributor administrator access because it is convenient. And do not declare the model finished after one meeting.
OWASP treats threat modelling as something that should be reviewed as the system changes. A new payment provider, login method, form, plugin or mobile app can change the data flow and create a new boundary. Schedule a short review after meaningful changes, not only once a year.
My Take
The best threat model for a small website is a living note that helps someone make a decision on a busy day. I would rather see five realistic scenarios with tested controls than fifty pages of generic warnings.
The most valuable question is often “What happens if this account is compromised?” If the answer is “the attacker can change everything,” reduce the blast radius. Separate administrator and daily accounts, restrict deployment permissions, protect recovery channels and make restoration possible. Security is not only about keeping attackers out; it is also about limiting what one mistake can unlock.
Bottom Line
Spend thirty minutes identifying valuable assets, tracing their paths and writing realistic failure scenarios. Rank those scenarios, assign practical controls and test the controls while the site is healthy. The result will not predict every attack, but it will turn vague worry into a short list of improvements you can actually maintain.