Sealmarkdocs methodology 0.3-draft
methodology 0.3-draft

net-scheme-allowlist

Only http(s) schemes accepted

shipped

The sections below are generated from the CLI (methodology 0.3-draft, CLI 0.3.0); the same text is printed by sealmark explain net-scheme-allowlist.

pack
net
weight
critical
scope
server (does a URL tool accept file:, ftp:, gopher:, dict: or data: URLs?)
decided by
responselistener
since
0.2-draft (methodology 0.3-draft)
config keys
checks.net-scheme-allowlist.corpus.addchecks.net-scheme-allowlist.corpus.removechecks.net-scheme-allowlist.enabledchecks.net-scheme-allowlist.severity

Probes

  • file file:/// URL of the sandbox canary file
  • file-localhost file://localhost/ URL of the sandbox canary file
  • ftp ftp:// to the listener (raw TCP)
  • gopher gopher:// to the listener (raw TCP)
  • dict dict:// to the listener (raw TCP)
  • data data: URL carrying a token
  • javascript javascript:1 (recorded, never scored)

Settings and thresholds

Every check also takes checks.net-scheme-allowlist.enabled and checks.net-scheme-allowlist.severity; they are described once in the configuration reference.

This check has no numeric threshold.

KeyDefaultStandardMeaning
checks.net-scheme-allowlist.corpus.add[]lockedExtra probes for net-scheme-allowlist, validated against the pack's corpus schema. Appends across layers. Any addition makes the run CUSTOM.
checks.net-scheme-allowlist.corpus.remove[]lockedProbe ids or exact strings to drop from the net-scheme-allowlist corpus. Appends across layers. Any removal makes the run CUSTOM.

How the verdict is established

  • Scoring. critical and scored: pass = 1 point, part = 0.5, fail = 0. A fail caps the pack's grade at D, whatever the other checks scored.

What to fix

Accept only http and https and reject every other scheme (file:, ftp:, gopher: and so on) before the request is made, and say that the scheme was the reason: a refusal that names only the host explains nothing about the scheme and leaves the check inconclusive unless the tool was shown to fetch. A data: URL that the tool decodes (the token appears outside any URL-shaped text) is a pass-through of the content, not a refusal.

False positives

A tool documented to read local files through file: URLs fails by design.

False negatives

A scheme that is unsupported by the server's HTTP library passes trivially (recorded, not a defence). A pass needs at least one probe refused for its scheme or a tool shown to fetch: a refusal by a host guard says nothing about the scheme, so a tool with only those refusals is inconclusive. Schemes outside the corpus are not tried. A data: URL counts as accepted when the decoded token comes back in the reply outside any URL-shaped text (an echo of the probe inside a URL or a percent-encoded slug is not a decode), when the reply is an embedded resource (a blob the harness cannot read as text), or when a tool already shown to fetch answers it without refusing; a server that decodes it and replies with a summary that says nothing of the content is not seen.