morphit/docs/adr/0006-security-posture-phase3a.md

# ADR-0006: Security posture for Phase 3a

**Status:** Accepted
**Date:** 2026-04-18
**Deciders:** project maintainer
**Supersedes:** none (complements ADR-0002 live-keys policy and
`docs/SECURITY.md`)

## Context

At the Phase-3a midpoint the maintainer raised specific concerns
from a security advisor — HTTP Parameter Pollution, SSRF, CSRF,
OAuth/nOAuth vulnerabilities, RCE, GuzzleHttp CVEs, xmlrpc.php
exploits, DDoS, maxlength enforcement, and related classes of
attack. Morphit is entering a phase where it begins accepting
untrusted HTTP input (the posting relay) and will soon host
large public-facing endpoints (indexer, orderbook). Formally
documenting which attack classes apply, which do not, and why
removes ambiguity for contributors, auditors, and future
phases.

This ADR classifies each attack vector into one of four verdicts:

- **Covered**: already mitigated in code or infrastructure.
- **Not-applicable**: structurally prevented by a design decision
  elsewhere (e.g. no PHP means no PHP-specific CVEs).
- **Deferred**: tracked for a later phase with a specific trigger
  for revisiting.
- **Out-of-scope**: cannot be solved in application code alone
  and belongs to the operator's deployment posture.

## Decision

The verdicts below are binding for Phase 3a. Any future change to
a verdict requires either a subsequent ADR or a note in the review
document of the phase where it is revisited.

### Architectural defense

Before listing specific attack classes, the following design
decisions eliminate large swathes of common vulnerability. These
are the load-bearing non-code defenses:

- **Non-custodial.** Morphit never holds user funds. There is no
  hot wallet to drain, no withdrawal mechanism to exploit, no
  custody contract to misconfigure. The worst outcome of a full
  relay compromise is that the operator loses the BLURT balance
  the relay itself holds for account-creation fees (tens to low
  hundreds of BLURT in practice).
- **No authentication layer.** There are no accounts on Morphit,
  no sessions, no passwords, no cookies, no JWTs, no OAuth.
  Every request is stateless. Entire vulnerability classes
  (session hijacking, credential stuffing, OAuth misconfiguration,
  nOAuth, CSRF-as-commonly-understood) do not exist here.
- **No user database.** Morphit does not collect KYC and does not
  log IP addresses. There is no user database to breach, no
  personal information to leak, and no data that could be
  compelled by subpoena.
- **No server-side dynamic code.** The relay has no `eval`, no
  `new Function`, no dynamic `require`, no template engines
  evaluating user input, and no server-side rendering of user
  input. Command-injection, template-injection, deserialization,
  and RCE via string-to-code paths are structurally impossible.
- **Chain-native orderbook.** Orders live on Blurt itself. The
  Morphit frontend is a reader; an indexer is a reader-with-cache.
  Takedown of any specific frontend does not delete orders —
  another frontend, self-hosted or community-run, can index the
  same chain data.

### Attack-class verdicts

#### HTTP Parameter Pollution

**Verdict: Covered.**

Every relay endpoint uses `zod` schemas with `.strict()` (rejecting
unknown keys) and explicit `.max()` bounds on every field. Arrays
have explicit length bounds. We do not read query parameters for
business logic; all input comes through parsed JSON bodies. Hono
gives exact header values, not arrays, so duplicate-header injection
produces a deterministic first-value-wins behavior we explicitly
control.

#### SSRF (Server-Side Request Forgery)

**Verdict: Covered.**

The relay only makes outbound HTTP calls to a pre-configured
allowlist of Blurt RPC endpoints parsed from environment variables
at boot. No handler accepts a URL from a request body. No
redirect-following is enabled. No arbitrary-fetch feature exists
anywhere in the codebase.

**Phase 3b update (Audit 2026-05 Finding 5-5):** the indexer
introduced the `morphit_operator_register_v1` op and federation
probe, which accepts an operator-supplied `origin` URL and fires
GETs against `${origin}/v1/health` to verify reachability. This
extended the SSRF surface beyond what was true in Phase 3a. The
defenses applied:

- The `operatorRegister` handler rejects loopback / RFC1918 /
  link-local / metadata-service / `*.local` / `*.internal`
  origins at registration.
- The `federationProbe.fetchJson` re-validates hostname at
  request time (defense in depth: a row that slipped past
  registration via direct DB write or a future regex-bypass
  is still refused).
- `redirect: 'manual'` on the fetch so a hostile server can't
  redirect the probe to localhost or a public IMDS.
- Response body is capped at 256KB (Audit 2026-05 NEW-9-11)
  with both Content-Length pre-check and streaming-with-abort.

The verdict remains **Covered**, but the structural argument
("no URL ever comes from a request body") no longer holds —
SSRF is now defended by explicit hostname allowlisting plus the
response-handling caps above.

#### CSRF (Cross-Site Request Forgery)

**Verdict: Not-applicable.**

CSRF is a vulnerability against cookie-based sessions: an attacker's
page causes the victim's browser to make an authenticated request
because the browser attaches cookies automatically. Morphit has
zero cookies, zero sessions, and zero server-side authentication
state. There is nothing the browser can "attach" that would
authenticate a third-party request.

Additionally, state-changing endpoints require inputs an attacker
cannot forge: the account-create endpoint needs the user's four
new public keys, which the user generates locally and which are not
available to any other origin.

An exact-match CORS allowlist provides defense-in-depth — the
browser blocks `fetch()` from any origin not on the list — but the
fundamental reason CSRF does not apply is structural.

#### Authentication vulnerabilities (AUTH-VULN-n, nOAuth)

**Verdict: Not-applicable.**

Morphit has no authentication. No login flow, no OAuth provider,
no password reset, no magic links, no SAML, no JWT, no API keys.
Classes of vulnerability that target these mechanisms cannot
apply to a system that does not implement them.

User identity on Blurt is cryptographic: transactions are signed
by the user's own keys on their own device. That authentication
belongs to Blurt; if it fails, the entire chain fails, not
Morphit specifically.

#### Remote Code Execution (RCE)

**Verdict: Covered, with caveats.**

- No dynamic code evaluation paths exist in relay or frontend source.
- No deserialization of untrusted binary formats. JSON is parsed
  through zod, which cannot produce prototypes or functions.
- Supply-chain CVEs remain a concern. `npm audit` must be run at
  deploy time and on every dependency bump (added to relay README).
  Lockfile (`package-lock.json`) pins exact versions.
- Node and nginx CVEs on the VPS are the operator's patching
  responsibility. Document this in the deployment guide.

#### GuzzleHttp CVEs

**Verdict: Not-applicable.**

Guzzle is a PHP HTTP client. Morphit has no PHP anywhere in the
stack. The relay is Node.js; the frontend is SvelteKit (also
JavaScript); the indexer (Phase 3b) will be Node.js; nginx
proxies without any PHP handler enabled. Guzzle CVEs cannot
apply.

#### xmlrpc.php exploits

**Verdict: Not-applicable.**

`xmlrpc.php` is a WordPress-specific endpoint. Morphit runs no
WordPress. No `xmlrpc.php` exists anywhere. nginx configuration
denies any request path outside `/v1/` on the relay, returning
404 without hitting the relay process.

#### Request-size / `maxlength`

**Verdict: Covered.**

- Relay-level: `maxRequestBodyBytes: 65536` (64 KiB hard cap).
  Oversized `Content-Length` is rejected before any body is read.
- Schema-level: every `z.string()` in every request schema has a
  specific `.max()` bound tuned to Blurt's on-chain constraints
  (name ≤ 16, json_metadata ≤ 1024, etc.).
- nginx-level: `client_max_body_size 64k` matches the relay.
- Frontend-level: HTML `maxlength` attributes on form inputs are a
  UX nicety, not a security boundary.

#### Volumetric / network-level DDoS

**Verdict: Out-of-scope.**

A single application cannot defend against a flood of 10 Gbps of
packets aimed at its network interface. This must be addressed at
the infrastructure layer: upstream DDoS scrubbing by the VPS
provider, a CDN (Cloudflare is the common choice), or a dedicated
mitigation service. Morphit's codebase explicitly does not try to
solve this.

Operators are encouraged to document their DDoS response plan
separately. Morphit mirrors that run behind Tor / I2P / Lokinet
naturally benefit from those networks' own DDoS properties.

#### Application-layer abuse / volumetric DDoS at L7

**Verdict: Covered.**

- Per-IP rate limits: 60 availability checks/min, 5 account
  creates/hour, enforced as sliding-window buckets in relay memory.
- nginx-level timeouts: 10s client-body-timeout, 15s send-timeout,
  30s keepalive-timeout.
- Resource ceilings in systemd: `MemoryMax=512M`, `TasksMax=256`.
- Relay is stateless beyond the in-memory rate limiters and a
  one-minute dedupe cache. A restart clears everything; no file
  or database grows unbounded.
- fail2ban integration is documented in the README: systemd
  journal entries of rate-limit rejections can be consumed by
  fail2ban to install temporary iptables bans without the relay
  itself logging or persisting IPs.

#### XSS (Cross-Site Scripting)

**Verdict: Covered at the frontend.**

- Strict Content Security Policy with `script-src 'self'` and
  hash-based inline-script allowlisting (configured in
  `svelte.config.js`).
- Svelte auto-escapes all dynamic content; `{@html}` is not used
  anywhere in the project (grep-verified in Phase 2 review).
- FAQ content is loaded from typed locale files, not user input.
- Relay never returns HTML — only JSON with `Content-Type:
  application/json; charset=utf-8` and `X-Content-Type-Options:
  nosniff`, so even if it somehow returned an XSS payload, no
  browser would render it.

#### SQL Injection

**Verdict: Not-applicable in Phase 3a; covered in 3b plan.**

The relay has no database. The Phase-3b indexer will use Postgres
with `sqlc`-generated parameterized queries only; no string
concatenation into SQL. Documented in `docs/PHASE-3a-DESIGN.md`
ahead of 3b.

#### Prototype pollution

**Verdict: Covered.**

Zod's `.strict()` rejects unknown keys including `__proto__`,
`constructor`, and `prototype`. We never use dynamic property
access (`obj[userKey]`) on user-supplied keys. No `Object.assign`
or spread-merge of user input into trusted objects.

#### Log injection

**Verdict: Covered, documented in SECURITY.md.**

The relay's `log()` function interpolates config values (relay
account name, endpoint URLs) which are schema-validated at boot
with no newline characters. No user-supplied string is ever
interpolated into a log line. Switching to structured logging
(e.g. Pino) is a Phase-4 improvement but not required for safety.

#### Timing attacks

**Verdict: Documented as minor, not fixed in 3a.**

The dedupe-check in the create endpoint uses linear scan and
string equality. The compared fingerprints are SHA-256 of
public data (the user's own new pubkeys, which are going on
chain), so any timing leak reveals only information the attacker
already has. The scan is bounded to the one-minute dedupe window
(at most ~5 entries given the 5/hr create limit). Documented in
SECURITY.md; not a fix candidate for 3a.

#### TOCTOU on availability check

**Verdict: Covered.**

Between the relay's `blurt.getAccount(name)` check and its
`broadcastAccountCreate`, another user could theoretically claim
the same name. If they do, the chain rejects the broadcast with
an `account_already_exists` error, which the relay catches and
maps to the `already_registered` error code (the same code
returned by the pre-broadcast check). The user sees one
consistent error message either way, and no funds are spent on
the failed broadcast (Blurt rejects it before the fee is
collected).

#### ReDoS (Regex Denial-of-Service)

**Verdict: Covered.**

The only regex in relay code (`/^(-?\d+(?:\.\d+)?)\s+\w+$/` for
asset amount parsing) runs on chain responses, not user input,
and has no nested quantifiers. Linear time in input length.

#### Dependency confusion

**Verdict: Covered.**

All dependencies (`@beblurt/dblurt`, `hono`, `@hono/node-server`,
`zod`) are on the public npm registry. No private-registry names
that could be shadowed.

#### Supply-chain / typosquatting

**Verdict: Mitigated; deferred for deeper work.**

- Lockfile pins exact versions and hashes.
- `npm ci --omit=dev` in deployment installs only what the
  lockfile specifies.
- Dependency count is deliberately small (4 runtime dependencies
  for the relay) so a compromise is bounded in blast radius.
- Full npm package signing is an open industry problem; we use
  what npm offers and accept the residual risk. Phase 5 can
  evaluate `npm-audit-resolver`, `socket.dev`, or similar.

#### Key exposure

**Verdict: Covered by ADR-0002.**

See ADR-0002 for the live-keys policy. The relay's own active
key is read once at startup from a file with `0400`
permissions; the relay refuses to boot if the file is
world-readable. The WIF string is never logged, never returned
in responses, never transmitted to any external service.

#### Legal/operator exposure

**Verdict: Policy, not code; documented in SECURITY.md.**

Operator considerations (sanctioned-country trades, takedown
requests, DMCA) are addressed by the project's structural
choices: the frontend never facilitates the actual trade, the
orderbook is chain-native and not controlled by any frontend,
and `@morphit` release-discovery ops are pinned to a specific
public key to resist impersonation.

### What this ADR deliberately does not address

- Threats to the Blurt chain itself. If Blurt's consensus breaks,
  Morphit breaks. That risk is inherent to the chain choice and
  is addressed in SECURITY.md.
- Threats from the user's own device (malware on the client,
  extension compromises, clipboard sniffers). Morphit minimizes
  its attack surface (live keys only, no owner/active in memory)
  but cannot defend against full local compromise.
- Physical access to the VPS. If the operator's server is
  physically compromised, the relay's active key is readable.
  Mitigation is the standard VPS-provider choice + disk
  encryption + quarterly key rotation; none of these are code.

## Consequences

### Positive

- Contributors and auditors have a single source of truth for
  "why isn't X a problem?" questions.
- Future phases can extend this ADR rather than argue each case
  anew.
- Unambiguous separation between code-level defense and
  operator-level responsibility.

### Negative

- ADRs tend to drift from reality. This one must be revisited at
  the start of every phase (noted in the phase review template).
- Some verdicts ("Not-applicable") rely on current design
  decisions (no PHP, no OAuth) that a future contributor might
  reverse without realizing the impact. The ADR is the warning.

### Follow-up work

- The relay README adds operator-level security guidance: npm
  audit, fail2ban, key rotation, BLURT balance monitoring.
- `docs/SECURITY.md` adds a user-facing threat-model section
  referencing this ADR.
- A Phase-3a FAQ entry (`security_attack_vectors`) in all 10
  locales points users at this material without requiring them
  to read the ADR directly.

## References

- ADR-0001: `custom_json` replacement ops
- ADR-0002: live-keys policy
- ADR-0005: Phase 3 subphase split
- `docs/SECURITY.md`: user-facing threat model
- `docs/PHASE-3a-DESIGN.md`: relay-specific design + security review