Threat modelling and secrets

Start with something worth protecting

Threat modelling is a structured way to ask what could go wrong in a particular design and how you would notice or prevent it. An asset is something you protect, such as a balance record or a credential. An entry point accepts input. A trust boundary is a place where input or authority crosses between parties with different permissions. A boundary is useful only when you can name the check that belongs there.

For a worked local design case, a browser supplies an account ID to an API. Authentication would establish who the caller is; authorization would decide whether that caller may read this account. A valid token belonging to user A does not authorize access to user B's account. A backend test needs both a permitted case and a cross-account denial case. Frontend hiding of a button cannot enforce that rule because a caller can address the API directly.

Use STRIDE as a question checklist rather than a score: spoofing asks about false identity, tampering about changed data, repudiation about missing accountability, information disclosure about unwanted reads, denial of service about exhausted resources, and privilege escalation about gaining unintended powers. One design can have several categories; counting categories is less useful than identifying a concrete missing check.

Practice on paper: select the API-to-database arrow, state which database role connects, and list the least operations it needs. Then select the browser-to-API arrow and state the account-ownership check you would require. These checks belong to different systems. The source review below tells you which application controls are actually missing.

Model the deployed system

Draw the browser, Accounts API, databases, outbox, emulator, and Ledger consumer. Mark where a request crosses a trust boundary and what identity is checked. Check the source to establish which routes the framework actually protects.

The current learning baseline has frontend Auth0 integration but no corresponding backend token-validation enforcement in Accounts. A login screen is not API authorization. Keep the exercise local with synthetic data. Backend authentication and object-level authorization require application changes and negative tests before any public deployment.

Separate secret mechanisms

Kubernetes Secrets do not automatically encrypt all storage or prevent authorized readers from retrieving values. Local fixture credentials are still kept out of public commits to practise good habits. Do not reuse actual cloud keys for Floci.

Document who can read runtime secrets and whether the application needs a mounted Kubernetes API token. You can evaluate an external secret store later; the current exercise needs only local fixture credentials.

Follow a secret through its lifetime

A secret must be created, delivered to the right process, used, rotated, and revoked. Keeping it out of Git addresses only one of those stages. If an environment variable supplies a credential at process startup, changing the Secret object does not rewrite that running process's environment. Plan compatible rotation: make the replacement credential valid, update its delivery, restart/reload as supported, verify access, and then revoke the old credential. Failure at each step needs an observed result, not an assumption.

For this local exercise, write that sequence for a fixture database credential without performing a rotation. Identify which file/Secret stores it, which process reads it, and how you would test rejection of the old credential after completion. External stores and dynamic leased credentials are optional later depth; they still need authentication, authorization, delivery, and revocation design.

Checkpoint

Write three threats with affected asset, entry point, existing control, missing control, and a test that would demonstrate improvement. Distinguish an observed missing control from a hypothetical exploit. Use this review to identify and test improvements while keeping the application’s unresolved risks visible.

Checkpoint guide: a useful row says “another caller can request this account ID; backend ownership enforcement is missing; add and test an explicit denial.” “Use zero trust” names no implemented check. Carry one specific, testable risk into scanning and hardening; neither tool category replaces the source-level authorization work.

Sources

MicroBank inspected source↗, Kubernetes Secret practices↗, and OWASP threat modelling↗.