dsh-route-fence-linter

Every webServer route registered by a Harness plugin is dispatched by longest-prefix match ahead of the host /api gateway, making each plugin author solely responsible for browser-trust verification. In practice, many plugins either ship no fence at all or compare Origin before pinning the Host, creating a DNS-rebinding window where an attacker who controls both headers can pass the check and execute state-changing operations.

dsh-route-fence-linter performs static source analysis over a plugin package's published files, grading each route handler against the canonical fence shape: pin the Host header to loopback or a configured trusted authority first, refuse cross-site fetch markers second, and compare Origin only last. The linter tracks register() calls across file boundaries, resolving inline objects, factory invocations, array spreads, and bare identifiers to the module where handlers are actually defined, then scores each handler independently—a single unfenced handler fails the entire registration. It also audits registerFallback for a wider attack surface and flags the DNS-rebinding-bypassable pattern where Origin equals Host but Host is never pinned to loopback.

It is designed for plugin developers performing pre-submission self-checks, security teams auditing installed plugin fleets, and CI pipelines needing a deterministic gate via exit codes 0, 1, or 2. For marketplace operators, it converts the previously manual, line-by-line fence review into a repeatable static check.