You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When safelyResolveURL is enabled, every external $ref fetch is gated by the built-in PermittedUrlsChecker, which runs a fixed pipeline — allowlist → denylist → restricted-IP-range — with the private/restricted-IP block always on and bypassable only by the allowlist. The checker is constructed internally (ResolverCache for OAS 3.0, ReferenceVisitor for OAS 3.1) with no public seam to substitute or extend it.
I'd like to propose an optional, pluggable URL-validation hook on ParseOptions. When set, the resolver routes every external fetch — top-level, direct, and transitive/nested — through it instead of the built-in checker. When unset, behaviour is unchanged.
Use case (generic)
Embedders often already have an outbound-request policy engine and need remote $ref resolution to obey it. The fixed order can't express several common policies, e.g.:
Deny a specific host while still permitting private/internal addresses — impossible today: the private-IP block is always on and only the allowlist bypasses it, but you can't enumerate "all private hosts".
CIDR / netmask rules — the lists match host patterns, not IP ranges.
Dynamic or context-dependent policy — per-tenant rules, externally-loaded config, decisions needing more than the URL string.
The goal is the same in all cases: keep the parser's safe-resolution flow (so transitive/nested refs stay gated) but let the embedder make the allow/deny decision.
The resolver would prefer the validator when present (e.g. a thin PermittedUrlsChecker subclass that delegates to it), keeping the existing checker as the default. To avoid a silent-bypass footgun it should be fail-closed: when a validator is set, verification runs even if safelyResolveURL is left false. Small additive change across ParseOptions, the safe-url-resolver, and the two construction sites. Happy to contribute a PR.
Feature Description
When
safelyResolveURLis enabled, every external$reffetch is gated by the built-inPermittedUrlsChecker, which runs a fixed pipeline — allowlist → denylist → restricted-IP-range — with the private/restricted-IP block always on and bypassable only by the allowlist. The checker is constructed internally (ResolverCachefor OAS 3.0,ReferenceVisitorfor OAS 3.1) with no public seam to substitute or extend it.I'd like to propose an optional, pluggable URL-validation hook on
ParseOptions. When set, the resolver routes every external fetch — top-level, direct, and transitive/nested — through it instead of the built-in checker. When unset, behaviour is unchanged.Use case (generic)
Embedders often already have an outbound-request policy engine and need remote
$refresolution to obey it. The fixed order can't express several common policies, e.g.:The goal is the same in all cases: keep the parser's safe-resolution flow (so transitive/nested refs stay gated) but let the embedder make the allow/deny decision.
Suggested shape (optional)
The resolver would prefer the validator when present (e.g. a thin
PermittedUrlsCheckersubclass that delegates to it), keeping the existing checker as the default. To avoid a silent-bypass footgun it should be fail-closed: when a validator is set, verification runs even ifsafelyResolveURLis leftfalse. Small additive change acrossParseOptions, the safe-url-resolver, and the two construction sites. Happy to contribute a PR.Related
RemoteUrlimplementation #1973 (provide ownRemoteUrlimplementation) — related, but about the HTTP transport rather than the allow/deny decision.