Threat models and trust boundaries

Objectives

By the end of the lesson, you can formulate a short threat model for a web operation (asset, actors, capabilities, protections), you can recognize trust boundaries, and you understand why one protection does not replace another.

Why is it not enough to learn the names of attacks?

The starting point of web security is not learning the name of an attack, but clarifying what we protect, from whom, and where data crosses a trust boundary. The same web application carries a different risk when it displays a public article and when it modifies a student's enrolment. Whoever knows only the names of attacks is at a loss before the next new attack; whoever knows the way of thinking can use it in a new situation too.

What are we trying to protect?

The assets to be protected in Kurzuspont: the student's personal data, the correctness of the enrolments, the logged-in session, and the availability of the service. The attacker can be an outside visitor, another logged-in student, a malicious web page, or a person using a stolen account. The security question is always tied to a concrete attacker capability: can the attacker read a response, can they get a browser to send a request, can they reach a server-side operation?

A threat model is a short description of which assets, actors, attacker capabilities, and protection conditions matter. It is not a prophecy about all future attacks: it helps rank the checks that the actual operation of the application requires.

Crossing trust boundaries

A trust boundary is the point where data or control moves toward another party, environment, or interpretation rule. User input does not become trustworthy by coming from the application's own form: code running in the browser and the network request can be modified, and the API can be called directly (with curl, with a script). The server must therefore recheck the user, their authorization, and the input at any modifying operation. A query sent to the database or a text displayed to another user is likewise a new interpretation context.

flowchart LR
    U[User or attacker] --> B[Browser and input]
    B -->|HTTP request: trust boundary| S[Application server]
    S -->|query: trust boundary| D[(Database)]
    S -->|HTML and data: interpretation boundary| B

The boundary does not mean that the other party is surely malicious, but that the receiver cannot rely solely on the sender's claim. The server, for example, cannot accept a hallgatoId ("student id") field in the request as evidence that the student is modifying their own enrolment. The identifier must be taken from the session checked by the server (7.4).

A simple line of thought for one operation

Take enrolment:

1. Asset: the correctness of the enrolments (nobody can enrol in another's name, the places cannot exceed the quota).
2. Operation: the server assigns a given student to a course.
3. Actors and capabilities: another student (can modify the request); a foreign web page (can make the student's browser start a request); a network attacker (sees traffic on public Wi-Fi).
4. Threats: a request arrives in another student's name; the browser sends the request with the logged-in cookie under the influence of a foreign website; the input becomes part of a database statement.
5. Protections: authentication, per-operation authorization checks, protection of the request's origin, correct handling of the input and the database operation.

A single protection does not replace the others: an encrypted connection (4.3) does not decide whether the given user may enrol in the course; nor does logging in prove that the request came from the student's intention.

flowchart TD
    A[Asset: correctness of enrolments] --> B[Attacker capabilities]
    B --> C[Threat: in another's name, from a foreign page, with manipulated input]
    C --> D[Protections: authentication, authorization, intent, input handling]
    D --> E[Is a gap left? Next boundary]

Worked example: the threat table of Kurzuspont

Asset	Attacker / capability	Threat	Main protection	Which lesson?
Students' personal data	Another logged-in student	Reads another's data by rewriting the identifier	Server-side authorization check	7.4
Correctness of enrolments	A foreign web page	Makes the browser start a request	CSRF protection	8.4
Displayed comments	A malicious commenter	Injects code into the page	Output encoding	8.3
Database	Any visitor	The input becomes a statement	Parameterized query	8.5
Accounts	Password guesser or phisher	Account takeover	Password protection, multi-factor authentication	8.6
Availability	Overload	The system does not respond	Capacity, limiting	Chapter 10

The table is a course-level sketch, not a complete analysis; its point is that every row is an asset – capability – protection triple, and every protection has a place in the architecture.

Common misconceptions

Statement	Clarification
"Only the login page is security-sensitive."	Reading personal data and state-changing operations are as well.
"Data coming from our own form is trustworthy."	The request can be modified arbitrarily by the client or another program.
"Security is a single switch."	Separate checks are needed at several boundaries.
"An HTTPS page is secure."	It protects the transport, not the errors of the application (4.3).
"A threat model is a long document."	Even a few lines of "asset – attacker – protection" are usable.

In brief

• A threat model names the assets, the actors, the capabilities, and the protections.
• At a trust boundary the receiving party cannot rely on the sender's claim.
• Data coming from the client must be rechecked on the server.
• Protections complement each other, they do not replace each other.

Review questions

1. What are the three main elements of a threat model?
2. Where are the trust boundaries in the enrolment operation of Kurzuspont?
3. Why is it not enough that HTTPS protects the enrolment request?
4. Why can we not accept the hallgatoId field given in the request?

Learning resources

• OWASP Top 10:2025 — the most important categories of web risk.
• Security on the web (MDN) — the topics of web security.