Threat models and authority boundaries

Prerequisites: Programming contracts and basic networking.

Learning objectives

• Construct a threat model.
• Distinguish authentication from authorization.
• Apply least privilege to a concrete workflow.

Security is a claim under assumptions

A threat model states what is valuable, who might threaten it, what capabilities they have, and which guarantees the design intends to preserve. A file-sharing service might protect document confidentiality, integrity of edits, and availability. Its adversaries may include unauthenticated visitors, malicious account holders, compromised browsers, or administrators with different levels of access. These are different models and require different controls.

Draw the components, data flows, and trust boundaries. A boundary is a place where data or authority crosses between principals or protection domains. A browser request is untrusted input even when the normal interface generates it. Client-side validation improves usability; the server still has to enforce the invariant.

Work an object-access decision

Suppose user Alice owns document 42 and Bob owns document 43. A request to GET /documents/42 carries Bob's valid session. Authentication establishes that the request acts as Bob. Authorization must independently decide whether Bob may read document 42. Checking only that a session exists creates an object-level access-control failure.

A useful decision is allow(subject, action, object, context). The context might include organization membership, document sharing state, and account status. The lookup and decision must refer to the same object and policy state. Hiding document IDs or making them difficult to guess is not a substitute for checking access.

Minimize authority and ambiguity

Least privilege gives a component only the authority required for its task. A thumbnail worker usually does not need permission to delete accounts. A capability is an unforgeable reference that conveys authority to a resource; possession may itself authorize an operation, so leakage matters. An access-control list instead records which principals may perform which actions. Both require careful lifecycle and revocation design.

Choose secure defaults. An unknown role or missing policy should not silently become administrator access. Log security-relevant decisions without recording secrets or unnecessary personal content. Treat denial paths as behavior to test, not exceptional code that never needs coverage.

Threat modeling is iterative. A new integration, export function, or background job can create another authority path. Review how credentials are issued, stored, used, rotated, and revoked. A diagram is useful only if it corresponds to executable enforcement and tested failure cases.

A complete argument also states residual risk. Rate limits can reduce automated abuse without preventing every malicious request. Encryption can protect a channel without preventing an authorized recipient from copying the content. The property and its boundary must remain explicit.

Practice problem

Design authorization checks for a private study-notes endpoint supporting read, update, and share. Give one positive test and three negative tests. Identify a background worker permission that should be excluded.

Worked solution

Use the authenticated subject from the verified session, then check that the subject owns the note or has an explicit grant for the requested action. A read grant must not imply update or share authority. Positive: an owner reads their own note. Negative: a different account guesses its ID; a reader attempts an update; a revoked collaborator attempts a read. Recheck policy on every request, including exports and background actions. A search-indexing worker may need to read permitted note fields, but should not be able to change ownership or grant sharing rights. Test that its credentials cannot perform those operations.

Check your understanding

A valid login establishes which property?

• Permission to read every object.
• The identity associated with the session, subject to the authentication scheme.
• That every request body is safe.
• That the user is an administrator.

Explanation

Authentication and object-specific authorization are distinct decisions.

Why is an unguessable document ID insufficient authorization?

• IDs cannot be long.
• The database will reject it automatically.
• A leaked ID may still be used by an unauthorized principal.
• It prevents sharing entirely.

Explanation

Secrecy of an identifier is not a replacement for the intended access policy.

Primary reading

• Computer Security textbook: UC Berkeley CS 161

Open the study and save your work →