Overview

BoxOffice leaves the laptop and goes to production in the cloud. Within a month, four stories land on the team's desk. A contractor's laptop is stolen, and on it is a .env file with the payment provider API key. The new mobile app needs users to log in, and someone proposes "just store the password in the app". At 10:00 on the day a stadium show goes on sale, bots grab 30% of the seat holds in the first minute and resell the tickets at three times the price. And a vulnerable library in the search service lets an attacker run code inside one pod — from where, in the default setup, every other service, the database and the Internet are one connection away.

None of these is a bug in a single line of code. They are design problems: where the network boundaries are, who is allowed to talk to whom, how identities are proven, where secrets live and how fast they can be revoked. This class treats security and networking the way the rest of the course treats scalability — as architecture decisions with trade-offs, made on purpose, drawn on the diagram, and defended in an interview.

Roadmap

1. This overview — security as design: threat modeling with STRIDE, defense in depth, and the OWASP API Security Top 10 mapped to BoxOffice. Identity — tokens, OAuth 2.1 and OIDC — was taught where BoxOffice first needed it, at the gateway: class 4 — Identity.
2. How the Internet works — layers, routing hop by hop and BGP, IP addresses and CIDR, public vs private addresses, NAT, subnets and the default gateway; two simulators (address explorer, packet walk through the BoxOffice VPC).
3. Cloud networking — VPC, subnets, route tables, Internet and NAT gateways, security groups vs NACLs, private endpoints, VPN and dedicated links.
4. Service mesh — data plane and control plane, sidecar vs ambient vs eBPF, mTLS, authorization and traffic policies.
5. Zero Trust, secrets & supply chain — never trust the network, workload identity, secrets management, SBOM, image signing and SLSA.
6. Quiz — check your understanding.

Slides

Click the slides and use ← → to move through them; F goes full screen and P opens the presenter view, with the notes. Open the slides in a new tab

Security is a design property

A common mistake is to treat security as a checklist applied at the end ("add HTTPS and a login page"). By then the expensive decisions are already made: the database sits in a subnet with an Internet route, every service shares one database password, the gateway is the only place that checks anything. Changing those later means re-architecting.

The alternative is to ask security questions while drawing the architecture, with the same seriousness as "how many QPS?". Three ideas organize the whole class:

Two words used throughout:

• Attack surface — the sum of all the points where an attacker can try to enter or extract data: public endpoints, open ports, dependencies, people with access.
• Blast radius — what an attacker can reach after one component is compromised. Good design keeps it small.

Threat modeling with STRIDE

Threat modeling is a structured conversation about a design: draw how data flows, mark where the level of trust changes, and ask systematically what could go wrong at each element¹. Adam Shostack summarizes it in four questions²:

1. What are we working on? — draw a data-flow diagram (DFD).
2. What can go wrong? — enumerate threats, for example with STRIDE.
3. What are we going to do about it? — pick a control for each threat (mitigate, accept, transfer, eliminate).
4. Did we do a good job? — review, test, repeat when the design changes.

Step 1 — the checkout data-flow diagram

A trust boundary is a line where data moves between components with different levels of trust: the Internet and our edge, our cluster and the payment provider, a service and its database. Threats concentrate on the boundaries.

flowchart LR
    subgraph internet ["Internet (untrusted)"]
        M(["Mobile app"])
        B(["Bot"])
    end
    subgraph edge ["Edge (public subnet)"]
        W["WAF + API gateway"]
    end
    subgraph cluster ["BoxOffice cluster (private subnets)"]
        O["order"]
        I["inventory"]
        P["payment"]
        A["auth"]
    end
    subgraph data ["Data (isolated subnets)"]
        DB[("PostgreSQL")]
    end
    subgraph ext ["Payment provider (3rd party)"]
        PSP["PSP API"]
    end
    M -->|"POST /orders + token"| W
    B -.->|"POST /holds × 10 000"| W
    W --> O
    O --> I
    I --> DB
    O --> P
    P -->|"API key, via NAT"| PSP
    PSP -.->|"webhook: payment captured"| W
    M -->|"login"| A

Five trust boundaries are crossed in a single checkout: Internet → edge, edge → cluster, service → database, cluster → provider and provider → cluster (the webhook). Each arrow is a question: who is calling, how do we know, and what can they do?

Step 2 — STRIDE

STRIDE is a mnemonic created at Microsoft for six categories of threat, each the violation of a security property¹:

STRIDE is applied per element of the DFD: processes are exposed to all six; data stores mainly to tampering, information disclosure and denial of service; data flows to tampering, disclosure and DoS; external entities to spoofing and repudiation².

Step 3 — rate the risk and decide

Not every threat deserves the same effort. A simple practice is to estimate likelihood × impact (low / medium / high) and act from the top of the list. The output of a threat-modeling session is a short table of threat → decision → owner, kept with the design document and revisited when the design changes.

Defense in depth

No single control is perfect: WAF rules have gaps, tokens get stolen, a library ships with a remote-code-execution bug. Defense in depth stacks independent layers, so that an attacker who defeats one still faces the next. The layers of BoxOffice, from the outside in:

flowchart LR
    U(["Client"]) -->|"1 · TLS, WAF, rate limit"| GW["API gateway"]
    GW -->|"2 · validate token (OAuth/OIDC)"| O["order"]
    O -->|"3 · check ownership (authZ)"| O
    O -->|"4 · mTLS + mesh policy"| P["payment"]
    P -->|"5 · subnet + security group"| DB[("PostgreSQL")]
    P -->|"6 · short-lived secret"| PSP["PSP"]

The layers are independent: the database security group does not care whether the token was valid, and the mesh policy does not care whether the WAF was bypassed. That independence is the point.

OWASP API Security Top 10 (2023)

The OWASP (Open Worldwide Application Security Project) publishes a list of the most critical risks of APIs³. It is the best checklist to bring to a design review, because almost every item is an architecture decision, not a typo. Mapped to BoxOffice:

Try it. Open the flash-sale scenario and press Run: watch how the burst when the sale opens (t = 60 s, our 10:00) saturates app and then inventory-db. Now select users and set its bot traffic to 0.45 — bots become about 30% of the requests (API6) — and run again. Which component would you add first, and where — WAF at the edge, rate limiting at the gateway, or the waiting-room queue? Use the full playground (↗) to add the components and compare p99 and the error rate (goals count only real users).

The network & security concept map

Security is not one box on the diagram: every hop of a request answers a different trust question. The map links each palette component (green) to the concepts it enforces (blue) and to the subpage that teaches them; the blue nodes are the layers of defense in depth:

flowchart LR
    client["client · mobile"]:::comp -->|"login"| auth["auth"]:::comp
    client --> waf["waf"]:::comp
    waf --> apigw["apigw"]:::comp
    apigw --> mesh["mesh<br/>(order, payment, …)"]:::comp
    mesh -->|"egress via nat"| pay["payment (PSP)"]:::comp
    vpc["vpc · subnet ·<br/>nat · vpn"]:::comp -.->|"contains"| mesh
    waf -.- c1["bots, rate limits,<br/>OWASP API4 / API6"]:::tech
    auth -.- c2["OAuth 2.1 + PKCE, OIDC,<br/>RBAC / ABAC / ReBAC"]:::tech
    apigw -.- c3["JWT validation (JWKS),<br/>strip identity headers"]:::tech
    mesh -.- c4["mTLS, SPIFFE identity,<br/>authz policy, NetworkPolicy"]:::tech
    vpc -.- c5["CIDR plan, public / private /<br/>isolated subnets, SGs"]:::tech
    pay -.- c6["secrets manager,<br/>dual-key rotation"]:::tech
    c4 -.- d1["Zero Trust: assume breach,<br/>default deny"]
    c1 -.- d2["STRIDE, OWASP API Top 10<br/>(this overview)"]
    classDef comp fill:#1e9e5a22,stroke:#1e9e5a
    classDef tech fill:#2f6fed22,stroke:#2f6fed

Related

• Components in the catalog: VPC, Subnet, NAT Gateway, VPN, Service Mesh; plus Auth Service and WAF.
• Classes: Traffic & edge (WAF, API gateway, rate limiting), Cloud-native (Kubernetes, CI/CD), Observability (audit trails, security alerts).
• Hands-on: 4 — Gateway & identity, 10 — Kubernetes, 11 — Delivery (image scan, SBOM, signed provenance).
• Case study: Payment system. Exercise: Design doc. Project: team project.

Key takeaways

What breaks next

Every caller in this class is a person or a service we wrote: the fan with a token, order with a workload identity, the pipeline with a signed provenance. The next caller is neither. Fans want to ask "two seats under R$ 300 on Saturday, hold them", and an assistant answers by calling catalog and inventory for them: a slow, expensive, non-deterministic dependency that can act on the inventory, on the fan's behalf, and can be talked into doing the wrong thing by the text it reads. Designing a system around a model — and deciding what it may touch — is class 13 — AI Systems.