Security mindset: trust boundaries and least privilege
Draw where trust changes, treat every crossing as hostile, and make the server check who may do what, on which object, every time.
Predict first
Before you read: predict
On ExamHall, any one exam admin can edit candidates' final grades and publish the results in a single step. Last term one admin's mistaken bulk edit reached 400 candidates before anyone else saw it.
Which change should the review ask for?
The 30-second version
A security mindset asks "what if the caller lies?". Draw where trust changes and treat everything crossing a boundary as hostile until the server validates and authorises it. Authenticate, then check this caller may act on this object; deny by default; give every identity least privilege; keep secrets out of code and logs. [S1, S2]
Draw where trust changes, treat every crossing as hostile, and make the server check who may do what, on which object, every time.
How it works
Step 1 of 9
Analogy: A national archive's retrieval desk and restricted stacks (archives)
A reader fills a request slip; the retrieval desk, not the reader, decides what leaves the stacks, judged against the archive's own register of clearances.
| At the archive | In the system |
|---|---|
| the retrieval desk checks each slip against the reader's clearance, every time, never the letterhead on the slip | the server authorises each request from its own record, not a value the caller sent (steps 2–4) |
| a reader's clearance is issued for her project | least privilege: each identity scoped to its job (step 6) |
| a box stays in the stacks unless a rule releases it | deny by default: closed until granted (step 5) |
| the most sensitive boxes have their own release procedure | separation of privilege for costly actions (step 8) |
| the catalogue is public; the lock is the desk's check, not a secret shelf number | open design: not security by obscurity (step 7) |
In real terms: the reader asks; the desk, from the archive's own register, decides what crosses the counter.
Breaks down when: a desk clerk can refuse a slip on a hunch. Software mediates mechanically, so the rule must be exact and deny by default (step 5).
Examples, run for real
EXH-2750, a candidate overwrites a classmate's answers. ExamHall's PATCH /attempts/:id/answers checked that the token was valid and then wrote the body to attempt :id. A candidate signed in with her own token changed :id to a classmate's attempt; the token was valid, so the write went through. Authentication had been treated as authorisation: the server confirmed who was asking but never that this caller was entitled to that attempt. The mindset lens surfaces it in review — draw the boundary at the request, then ask "what if the caller lies about :id?" (steps 1–3). [S1, S2]
MR !3050 fixes it by authorising the object for the caller. The mechanism that fixes it is owned by sec-bola-idor; this lesson teaches only the stance that finds it: every value the caller sends, :id included, is a claim the server must check against its own records, not trust because a token was valid (step 4). [S1]
So the lesson here is the review habit, not the defect catalogue: name each trust boundary, ask what the caller controls across it, and make the server decide — the general principles the rest of this lesson drills, one per item.
Try it
Answer first, then check. Nothing is saved.
Question 1 of 6
A video-streaming service's thumbnail generator connects to the database with the same admin account the app uses. Its job only reads frame timestamps from one table, videos.
What should the review change?
Question 2 of 6
A ticketing API's order export sends every column of the orders table except the ones on a hidden list (card_last4, internal_notes). Next week a migration adds a buyer_phone column.
How should the export choose its columns?
Question 3 of 6
A payments team's refund links carry a token made by running the order id and amount through a scrambling routine the team wrote and keeps private. A reviewer flags it.
What should the review ask for?
Question 4 of 6
Draw the trust boundaries for ExamHall's submit-and-grade flow (candidate browser → API → database; proctor console → API; webhook → you).
Pick one boundary and run a premortem: name one thing that could go wrong there and the server-side control that prevents it. ≤150 words, as boxes and arrows.
Question 5 of 6
At a box office one staff account can both issue a refund and approve it. A review flags it.
Which change follows the principle?
Question 6 of 6
You said a video-streaming platform's server checks the moderator role on every takedown. The interviewer follows up: "For speed we cache that authorization after the first check, and a moderator is removed mid-session. What must happen?" You give one answer.
Which answer survives?
Go deeper
Pro tip
- In a review or design round, draw the trust boundary as a line and ask of each crossing: "what if the caller lies about this?" Name, for each arrow, what the server re-checks (identity, the object, the default). When: any endpoint or design review. Status: SELF (this lesson's practice target; not a cited key).
- A secret in a commit, a log, a ticket or an AI prompt is leaked: rotate it first, then investigate. Deleting the message does not un-leak it. Status: SELF (owned fully by
sec-secrets-management; stated here as the mindset habit).
Related lessons
Checked against the tools and docs as of 2026-10-19.