CertScope-Public/docs/THREAT_MODEL.md

Threat model

Assets

CertScope protects the host running the inspector from becoming a generic network pivot while preserving enough evidence to troubleshoot public DNS/TLS/HTTP posture. It also protects report consumers from misleading scores and unescaped exported content.

Primary threats

1. SSRF into private infrastructure. A user-controlled hostname or redirect could resolve to loopback, link-local, RFC1918, CGNAT, ULA, multicast or other non-public space.
2. DNS rebinding / TOCTOU. A safe first lookup could be followed by a different answer before a socket is opened, or a redirect target could resolve privately.
3. Port and scheme escalation. A redirect could attempt file:, credentials, protocol confusion or an arbitrary port.
4. Unbounded work. Redirect loops, many addresses or stalled DNS/sockets could consume server resources or create concurrent connection pressure.
5. Misleading partial evidence or stale provenance. A failed record family or hop could be mistaken for an absent control, or a failed new request could make a prior demo report appear live.
6. Report/content injection. Hostnames, headers and diagnostic text could break the UI or Markdown exports if rendered without escaping.

Controls

• hostname-only input validation, lower-case normalization and safe IDN-to-ASCII conversion;
• public-unicast validation for every resolved A/AAAA answer before any candidate is attempted;
• direct IP connection after validation, retaining the normalized hostname only for Host/SNI, so the connect path does not ask the OS to resolve the hostname again;
• bounded multi-address fallback with a hard total deadline and recorded candidate failures;
• re-resolution and target validation for every redirect hop;
• HTTP(S)-only, default ports only, maximum three redirect hops, normalized visited-URL loop detection and explicit HTTPS downgrade blocking;
• four-second DNS, eight-second TLS and 15-second HTTP aggregate budgets, plus per-operation timers and socket/response teardown;
• explicit collector _meta.status and error evidence, with score deductions applied only to observed evidence;
• client-side structural validation before a successful API payload can replace a valid report, plus retained and explicitly labelled prior evidence on request failure;
• typed header posture shared by diagnostics and UI, including CSP first-directive-wins behavior, browser-style Referrer-Policy fallback lists and Unavailable rather than inferred negative controls;
• deterministic, non-AI diagnostic rules with stable IDs and an equal-weighted category score;
• React escaping for UI values and length-safe Markdown escaping/fenced JSON exports;
• process-local four-slot admission and 30-per-minute fair-use limiting. Forwarded headers are ignored unless an operator explicitly trusts the reverse proxy;
• no persistence, credential handling, arbitrary shell execution or background jobs in the MVP;
• container non-root, read-only root filesystem, dropped capabilities, no-new-privileges and bounded temporary storage.

Residual risk and assumptions

The deployment is intentionally unauthenticated and should be kept behind the intended network boundary or an operator-controlled access layer. The process-local limiter is not shared across replicas. DNS and public routing can change after an individual validated connection; CertScope makes no claim about future state. It also does not inspect response bodies or prove application-level authorization.

Out of scope

CertScope does not perform port scanning, subdomain enumeration, vulnerability exploitation, authenticated crawling, private-network inspection, history persistence, monitoring daemon work or multi-host inventory.