Threat model

2026-09-21 · Threat model

This covers the app network: the single-purpose tools under bryancalabro.com, and the build and deploy path behind them. Everything here describes code and configuration that exists, and each claim names how it was checked.

Assets

The first row is the one worth being careful about, and it is the one the architecture is built around.

Trust boundaries

1. Visitor's browser to my origin. The only thing that crosses it is the static bundle, in one direction. The apps make no API calls of their own.
2. Visitor's browser to Google Fonts. The one third-party origin any app talks to. It sees the request for the stylesheet and the font files, which means it sees the visitor's IP and user agent. This is the weakest claim on the page and it is stated plainly rather than buried.
3. My machine and the agent to GitHub. Everything that reaches production goes through a pull request here.
4. GitHub to the host. The build runs on the host's runner and serves the output.

What is local-only, and how that was verified

The claim: what a visitor types into any of these tools never leaves their browser.

How it is checked, rather than asserted:

• No network calls exist to make. The apps have no fetch to any origin of mine. There is no backend to receive anything, so there is no endpoint to misconfigure.
• No analytics in the apps. Vercel Analytics runs on the calabrodesign site only.

• Storage is namespaced and inspectable. Each app writes one JSON object to localStorage under bc:<host>. Open dev tools and the entire stored state is one key, readable in full. Nothing is hidden in IndexedDB or a cookie.
• The strictest case is enforced, not documented. SQLpad takes dropped CSV files. Its query text and saved queries persist; the CSV contents deliberately do not. Dropped tables live in memory and in the Web Worker, and are gone when the tab closes.
• A Content Security Policy that would break if this changed. connect-src 'self' on the desks, and no permitted third-party script origins. A future fetch to somewhere else fails loudly rather than silently succeeding.

What this does not protect against

Stated because a threat model that only lists wins is marketing.

• Anything with access to the visitor's machine. localStorage is not encrypted and is not meant to be. A shared or compromised machine reads everything the tools stored, and the mitigation is that the tools store what a browser would anyway.
• A malicious dependency. The apps have a small tree, pinned by lockfile, but a compromised package would run in the page with full access to what was typed. This is the realest risk on the page and the one with the weakest current control: the lockfile and dependency audits are the whole of it.
• Google Fonts. Boundary two. Self-hosting the fonts would close it and is the obvious next hardening step.
• Anyone who controls DNS or the deploy. They serve whatever they like.

• A person reading over a shoulder. Cipher Score analyses passwords in the page; the page is on a screen.

The one that is still open

Recorded as noted, not as fixed. Relative OG URLs and an under-wired apple-touch icon are not a security finding in themselves, but a review finding that was seen and never closed is exactly the pattern that hides one that is.

The fix in the current build is structural: every app and every desk generates its favicons and its 1200x630 OG image from one source with npm run chrome, writes absolute OG URLs, and a smoke check fails the build if any of those files is missing from the output. That is what makes this the last time.