# 16. Security

How to build security into the architecture: threat modeling, least privilege, authn/authz, secrets, audit, and secure defaults.

- **Author:** Fedor Chishchin
- **Level:** advanced
- **Reading time:** ~25 minute read
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/learn/software-architect-16-security

---

## 1. The core idea

Security starts with one question: who do we trust, why, and what happens if that trust is broken?

### Authn and authz are different things

> A passport proves who you are. A ticket proves you're allowed into the hall. They aren't the same document.

Authentication answers "who is this?" Authorization answers "what are they allowed to do?" The common mistake is to verify identity correctly and then forget to check access to the specific resource.

The architect has to define the permission model: RBAC, ABAC, ownership-based access, tenant isolation, service-to-service permissions. Most importantly, authorization belongs at the level of the business action — not just the endpoint.

### Least privilege shrinks the blast radius

> Your apartment key shouldn't open the whole neighbourhood. If it gets stolen, the damage has to be bounded.

Every user, service, token, and job should hold the minimum rights it needs. Secrets don't live in code. Production access is restricted, logged, and reviewed on a schedule.

A security architecture isn't only about the probability of an attack — it's about the blast radius: what an attacker can actually do once they've compromised one component.

## 2. Example and anti-example

A good security model makes the safe path the easiest path for the developer.

### Example: tenant isolation in the repository

> In an office building, each tenant has their own locked door — not a sign that reads "please don't come in."

All data access goes through a repository that requires `tenantId` from a trusted context. Query builders inject the tenant predicate automatically, and integration tests assert that cross-tenant reads are impossible.

That's better than asking every developer to remember the filter by hand.

### Anti-example: an admin flag in the JWT, no resource check

> A "staff" badge doesn't entitle you to open the safe, the accounting office, and the server room.

The API checks `isAdmin=true` and stops there — no check on workspace, role scope, or ownership of the resource. One token grants too much. If it leaks, the damage is maximal.

Authorization has to be contextual: subject, action, resource, tenant, conditions.

#### Self-check

- Where are the trust boundaries in the system?
- What happens if one service token leaks?
- Where is authorization checked at the resource level?
- Which actions end up in the audit log?

Next module: [Observability](./software-architect-17-observability).