Security Review Mode: Any Architecture, Ten Questions
A repeatable interrogation you can run against any system diagram — yours, a candidate's, a vendor's — that produces specific findings in under an hour without needing to know the codebase.
Frame the problem
Security starts with a concrete asset, attacker capability and trust crossing.
The ten questions
These are ordered so that each answer constrains the next. They work on a whiteboard sketch, on a system design interview answer, and on a vendor's architecture document. Nothing here requires reading code; the point is to find the questions that *should* send you to the code.
The discipline is to refuse vague answers. "We use OAuth" answers nothing about authorization. "It is internal" answers nothing about reachability. Every answer must name a mechanism, a place it is enforced, and what happens when it is not there — and the answers that cannot be given are the review's output.
- 1. What are the assets? Specific nouns. If the answer is "user data", ask which table and which columns.
- 2. Who are the identities? Humans, services, jobs, CI, agents, partners. Each should have its own, and if two things share one, ask why.
- 3. Where are the trust boundaries? Draw them. Every arrow crossing one must name what it validates.
- 4. What is public? Everything reachable without credentials, including the ones nobody meant to publish.
- 5. What is privileged? Which operations grant access, move money, change infrastructure, or delete data — and who can invoke them.
- 6. How is authentication performed? For humans and for services. Ask specifically how a service proves its identity to another service.
- 7. How is authorization enforced, and where? The answer must be a layer and a mechanism. "In the controllers" is a finding waiting to happen; "in the repository layer, tenant-scoped by construction" is an answer.
- 8. Where are the secrets? How they are stored, how they reach the workload, how they rotate, and who can read them.
- 9. What input is untrusted, and where is it parsed? Including queue messages, webhooks, uploaded files, database columns written by other systems, and content retrieved by agents.
- 10. What happens if a component is compromised? For each component in turn: what credentials does it hold, what can it reach, what would we see, and how would we recover?
Follow-through: abuse, detection, recovery
The ten questions establish the design. Three follow-ups establish whether the design survives contact with an adversary.
How is abuse limited? Not just rate limiting: what stops one account from enumerating every resource id, exporting the entire dataset through a legitimate endpoint, or creating unlimited objects? Business-logic abuse uses only authorized operations and is invisible to every control that asks "may this identity do this?"
How is the system monitored? Ask for the specific alert that would fire for three concrete scenarios: a stolen session used from a new country, a service reading a table it has never read, and a spike of authorization denials on one resource type. If those alerts do not exist, detection is theoretical.
How do we recover? Can sessions be revoked in bulk? Can a credential be rotated without downtime? Is there a tested restore? Can you enumerate what an identity accessed in the last 30 days? Recovery capability is the least-exercised part of most systems and the part that determines how long an incident lasts.
SYSTEM: order management, reviewed 2026-08-19, 55 min
ANSWERED WELL
authn (human) session cookie, HttpOnly/Secure/SameSite=Lax, 12 h, rotated on privilege change
secrets fetched at boot from the secret manager via workload identity, 24 h rotation
untrusted input parsed at the HTTP edge into typed values; queue consumer does the same
FINDINGS
F1 authorization is enforced per controller; 3 of 41 routes have no check CRITICAL
→ move enforcement into the repository layer; make an unscoped query a type error
F2 reporting service holds the same DB role as the app (read+write, all tables) HIGH
→ separate read-only role limited to reporting views
F3 no alert exists for "service reads a table it has never read" MEDIUM
→ add; this is the detection for F2's residual risk
F4 bulk export endpoint has no per-account volume limit MEDIUM
→ business-logic abuse: all operations authorized, outcome not intended
UNKNOWNS (not examined)
mobile API authorization model; partner webhook receiver; backup restore pathKey points
- Ten questions in order — assets, identities, boundaries, public, privileged, authn, authz, secrets, untrusted input, compromise — then abuse, detection and recovery.
- Refuse vague answers. Every answer names a mechanism and a place it is enforced.
- "What happens if this component is compromised?" asked of each component in turn produces the best findings.
- Business-logic abuse uses only authorized operations, so ask about it separately from authorization.
- Publish the unknowns alongside the findings, so nobody reads a short report as a clean bill of health.
Secure This Architecture
Change the system and observe which assumption moves.
A legitimate, authenticated user changes a resource id in the URL.
If it works: Cross-tenant disclosure through traffic that looks entirely normal.
Residual: Sharing, delegation and support tooling bypass ownership by design.
Prevented by Resource-scoped authorization · contained by Row-level tenant policy · seen by Audit log or Anomaly alerting
- • None yet.
- • Credential read in transit
- • Anonymous caller reaches a privileged operation
- • Credential stuffing
- • Customer reads another customer’s record
- • Input interpreted as SQL
- • Stolen session replayed
- • Database reachable beyond the backend
- • Database credential leaks
- • Compromised backend exfiltrates data
- • One request exhausts the database
- • Unexpected shape reaches business logic
- • No record of a privileged action
- Add a control to see what survives it.
- • Whether each control is actually applied on every endpoint, or only on the ones that were reviewed.
- • What the admin, support and reporting paths do — they usually bypass ownership checks by design.
- • Where copies of this data already exist: replicas, backups, exports, search indexes, logs, analytics.
- • Whether revocation and restore have ever been exercised, rather than merely implemented.
Follow the attack
Safe conceptual simulation: capability → missing control → crossed boundary → asset impact.
- 1Attacker → the question that could not be answered, because an unanswerable question is an unowned mechanism.
- 2Unowned mechanism → a gap that no test covers and no alert watches.
- 3Gap → asset, along whichever specific path the relevant lesson describes.
- Unreviewed designs ship boundary assumptions that are expensive to change later.
- A review that produces only vague findings consumes the team's appetite for reviews without reducing risk.
Defend, detect, recover
One prevention is a single point of security failure. Layer it and make failure observable.
- • Run the ten questions at design time for anything touching a new boundary, asset class or actor.
- • Require the answers in the design document, so the review is checking claims rather than discovering the system.
- • Turn each finding into a test where possible — an unscoped query that fails to compile beats a note in a document.
- • Track which findings recur across reviews; a repeating finding is a platform problem, not a team problem.
- • Measure whether claimed mechanisms exist in production by sampling — grants, headers, alerts, rotation timestamps.
- • After an incident, run the review against the affected system and check whether the answer given previously was accurate.
- • A mechanism claimed in review and absent in production is the highest-value process finding available.
- • A review samples the design at a moment; the system changes weekly.
- • Reviewers find what they know to look for, and the ten questions do not cover privacy, safety or organisational risk.
- • Answers are given by the people who built it, who are also the people least able to see their own assumptions.