Threat Model & OWASP ASVS L1 Self-Attestation

This model covers the production deployment of vaulted.fyi including its web frontend, API routes, and Upstash Redis storage. It also covers the published CLI and MCP server insofar as they interact with the same API.

Out of scope:

• The user's endpoint device (browser, OS, extensions, clipboard, screen).
• The communication channel through which the share link is delivered (email, Slack, SMS, etc.).
• The recipient's subsequent handling of the plaintext.
• Vulnerabilities in Vercel or Upstash beneath the API surface we consume.

Primary asset: the plaintext secret. It must never reach the server, persist outside the sender's and recipient's browsers, or be recoverable from server-side state alone.

Secondary assets: ciphertext, IVs, view counters, expiry timestamps, and the integrity / availability of the service.

Trust boundaries (in order of decreasing trust):

1. Sender browser — trusted with plaintext and key.
2. Recipient browser — trusted with plaintext and key after entering the link.
3. Network between client and server — untrusted; mitigated by TLS 1.3 and the design choice that only ciphertext crosses it.
4. Vaulted server (us) — semi-trusted. Treated as a passive ciphertext store. The threat model assumes Vaulted itself could be compromised without exposing plaintext.
5. Upstash Redis — same trust level as the server. Encrypted blobs only.

Passive network observer. ISP, on-path actor with access to TLS metadata. Defeated by TLS and by the absence of plaintext or key on the wire.

Active network attacker. Can attempt to MitM. Defeated by TLS, HSTS preload, and certificate validation. A successful TLS compromise still yields only ciphertext.

Compromised server / hostile operator. Includes us. Cannot read stored secrets because the key never arrives. Can deny service or modify the served JS bundle — addressed in residual risks below.

Unauthenticated attacker with a valid share link. By design, anyone with the full link can decrypt. View limits, expiry, and optional passphrase reduce the window. This is a deliberate property, not a bug.

Targeted attacker against a specific sender or recipient. Can exploit the endpoint, the delivery channel, or the recipient's post-decryption handling. Outside Vaulted's control; documented for honesty.

• Client-side AES-256-GCM with random 96-bit IVs from crypto.getRandomValues.
• 256-bit keys generated per secret via crypto.subtle.generateKey; placed in the URL fragment, never transmitted.
• Optional passphrase wrapping with PBKDF2 (high iteration count) and AES-GCM key wrap.
• Atomic view-count enforcement via Redis HINCRBY with same-transaction deletion at limit.
• TTL-based auto-expiry capped at 30 days; no extension after creation.
• Per-IP sliding-window rate limiting on create and view endpoints.
• noindex on /s/[id] view pages so secret URLs cannot leak via search.
• TLS 1.3 with HSTS preload, secure security headers, no IP logging beyond rate-limit windows.

These are deliberate boundary decisions, documented so users can decide whether Vaulted fits their threat model.

• Endpoint compromise. A keylogger, infected browser, or hostile extension can read plaintext after decryption.
• Delivery-channel leak. If the share link is forwarded, archived, or quoted in a replied email thread, that channel becomes the attack surface.
• Targeted bundle swap. A compromised CDN or Vercel edge could serve different JS to a specific user. Subresource Integrity and reproducible builds are partial mitigations and on the roadmap.
• Recipient behaviour. Once decrypted, the recipient can copy, screenshot, or forward.
• Weak passphrase. If used, a weak passphrase is brute-forceable by anyone with the wrapped key.
• Rubber-hose / coercion. Out of scope for any technical control.

The matrix below maps Vaulted's implementation against selected OWASP ASVS Level 1 requirements. Categories that don't apply (sessions, authentication, file upload) are marked N/A with a brief rationale rather than omitted, so absence of an entry doesn't read as evasion.

Numbering follows the ASVS 4.0 structure. The list is selected, not exhaustive — the goal is honesty about the controls that meaningfully apply to a stateless, account-less encrypted ciphertext store.

Any change that affects an item in this document — new endpoint, cryptographic change, dependency-affecting refactor, infrastructure change — must trigger a review of this page in the same PR. The version and published date above will increment when the document is updated; the prior version remains accessible in the public git history.