proxyabl SSRF engine is dead code — wire assertUrlSafe into the router or correct the marketing

[davidcrowe]

Problem

proxyabl's headline claim is SSRF protection, but the good engine is dead code. proxyabl-core's assertUrlSafe/executeProxyRequest (DNS-rebinding-aware, resolves all A/AAAA, unpacks IPv4-mapped IPv6, redirect:"manual") is exported and unit-tested but imported by NOTHING outside its own tests. The middleware wrapper and apps/gateway-server route /proxy through packages/proxyabl/src/router.ts (raw fetch, lines ~426/588/856) with a weaker host-equality + path-allowlist check and no private-IP/DNS validation.

A reviewer who greps for assertUrlSafe finds zero consumers — the thing being marketed is not the thing running. During a star push this is a credibility hole.

Fix (pick one)

• Preferred: route the gateway's /proxy handler through executeProxyRequest/assertUrlSafe so the marketed engine is the one that runs. Retire the raw-fetch path in router.ts.
• Or: if the router's model is intentionally different, update the README/docs/packages.md to describe what actually runs, and demote the SSRF-engine claim to "available primitive."

Related (convergence)

Production (gatewaystack-connect) forked this same engine into integrations/custom/security.ts in Feb 2026 and each side now has fixes the other lacks (OSS has extractIpv4MappedIpv6; prod has redirect-revalidating safePublicFetch). The real fix is one canonical proxyabl-core engine consumed by both — see the prod convergence epic. This issue is the OSS half: make proxyabl-core's engine actually load-bearing in OSS.

Acceptance

• assertUrlSafe (or the full engine) has a real consumer in the gateway path, OR the marketing is corrected to match reality.