Chapter 8 — Security architecture basics
Lesson map
Lesson 08 published. Map, example, EX022.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Layers"]
N2["8.2 Trust boundaries"]
N3["8.3 Separating clients"]
N4["8.4 Environments"]
N5["8.5 Standard architecture"]
N6["8.6 Exceptions"]
N7["Applying the standard"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX022"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Layers"]
N2["8.2 Trust boundaries"]
N3["8.3 Separating clients"]
N4["8.4 Environments"]
N5["8.5 Standard architecture"]
N6["8.6 Exceptions"]
N7["Applying the standard"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX022"]
[Learning outcomes]
|
v
[8.1 Layers]
|
v
[8.2 Trust boundaries]
|
v
[8.3 Separating clients]
|
v
[8.4 Environments]
|
v
[8.5 Standard architecture]
|
v
[8.6 Exceptions]
|
v
[Applying the standard]
|
v
[Worked example] --> [Exercise EX022]
Learning outcomes
You will (1) apply layered defences to client apps; (2) place trust boundaries; (3) separate environments and clients; (4) document a standard architecture.
8.1 Layers
Edge protections (HTTPS, rate limiting), application controls (validation, authorisation, encoding), data protection (encryption, least-privilege database accounts) and pipeline controls (reviews, dependency checks, isolated builds). For the Greenleaf upload feature, each layer adds a separate obstacle. The edge limits request rates, the application checks file type and size, the data layer keeps uploads in their own bucket, and the pipeline flags an outdated upload library. If one layer misses a problem, another still has a chance to catch it. Diego lists each layer's controls per client, so gaps in any layer are visible.
8.2 Trust boundaries
Boundaries exist between visitor and app, app and database, app and external services, build and production, and between clients. Each boundary gets a check. The January flaw crossed the visitor-to-app boundary, because any visitor could upload a file. The library itself crossed the boundary from the public registry into Brightwave's build. Diego marks both on his diagrams so each gets a named check. Other boundaries matter as much: between build and production, the approved-image rule decides what may run, and between clients, separate databases and buckets stop one site reading another's data. A boundary without a named check is treated as a gap to fix.
8.3 Separating clients
Each client has its own database, storage bucket and secrets. A flaw in one client's app cannot read another client's data. This is exactly what was missing for the two small clients Diego finds sharing one database with separate tables. A flaw in either site could have read the other's records. Splitting them into separate databases restores the rule and removes an exception nobody had recorded. Separate secrets mean a leaked key for one client cannot send email or take payments for another. Separate buckets mean an upload flaw in one site cannot list or read another client's files.
8.4 Environments
Test and production are separate, with separate secrets and data; test uses synthetic data only. Keeping test data synthetic matters for Greenleaf, whose real data includes pet medical notes. A developer debugging a booking bug in test never sees a real owner's details, and a leaked test database exposes nothing real. Separate secrets also mean a test key cannot send real confirmation emails or take real payments by mistake. Production deployment rights are also limited to two developers, which keeps the environments separate in practice and not only on paper.
8.5 Standard architecture
Brightwave writes a one-page standard for new projects, so security decisions are made once and reused. The standard covers the decisions that came up repeatedly in client projects: separate database, bucket and secrets, least-privilege database accounts, HTTPS and rate limits at the edge, server-side authorisation, and a pinned and reviewed pipeline. Writing these down once means a new project inherits them rather than relying on each developer to remember. Each line of the standard points to the ASVS requirement it comes from, so a developer who wants the reasoning can follow it. Aiko reviews the checklist before a new project's first production deployment.
8.6 Exceptions
Projects that differ from the standard record why. An exception records what differs, why, which extra checks compensate and who approved it. A client needing an external payment provider is a typical example that Brightwave accepts. The shared database Diego found was different: an unrecorded exception that nobody had decided on, which is why it was fixed rather than written down. Recorded exceptions are reviewed with the standard so that temporary ones do not quietly become permanent. Each recorded exception also names a review date when it is checked again.
Applying the standard
For each new project, the lead developer fills in a short checklist against the standard: separate database, bucket and secrets; least-privilege database account; HTTPS and rate limits at the edge; server-side authorisation; reviewed and pinned pipeline. Aiko reviews the checklist before the project's first production deployment. Where a client needs something different, such as an external payment provider, the difference and its extra checks are written down. Over the year, the checklists also serve as evidence when clients ask how their site is protected, which saves the team time answering security questionnaires.
Why one page
A one-page standard is short enough that developers actually read it. Longer guidance lives in linked notes, and each line of the standard points to the ASVS requirement it comes from.
Worked example
Applying the standard to existing clients, Diego finds that two small clients share one database with separate tables. They are split into separate databases during the next maintenance window.
Synthetic case. The architecture is synthetic.
Errors and limits
A standard helps only if followed; check new projects against it.
Exercises
- EX022 — Four layers. List the four layers. Rubric: 3 = edge, application, data, pipeline; 2 = three; 1 = one; 0 = none.
- EX023 — Client separation. How are clients separated? Rubric: 3 = own database, bucket, secrets; 2 = two; 1 = one; 0 = none.
- EX024 — Shared database. What was found and fixed? Rubric: 3 = two clients sharing a database; split; 2 = partial; 1 = vague; 0 = none.
Synthesis
Layer controls, guard boundaries and separate clients by default.
Continue studying — chapter 08 of 30
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →