What request forgery does an authorization server or client invite when it fetches a URL another party supplied?

## Where an OAuth deployment fetches a URL A deployment that configures every endpoint statically makes no such fetches. Discovery-driven ones make several: - an **issuer identifier**, from configuration or from a party, converted into the location of an authorization-server metadata document at the `/.well-known/oauth-authorization-server` path; - the **`jwks_uri`** found inside that document, fetched to obtain verification keys and re-fetched on rotation; - **URLs submitted when a client record is created**, which a server may dereference to display or validate something; - health checks and admin tooling that will happily fetch whatever an operator pastes in. The common shape is: *a value arrives from outside, and a server inside your network turns it into an HTTP request*. ## Why that fetch is the attacker's request An external attacker's own requests arrive at your edge and are filtered there. A request your server makes on their behalf does not. It starts inside, carries your source address, and may pass through no filter at all. That single change of origin is the whole vulnerability, and it is why input validation phrased as "escape it" misses the point - nothing is being injected into a string. A destination is being chosen. What the attacker gets, in rough order of severity: - **Reach** to services that are only listening internally and were never designed to be exposed. - **Effect**, where an internal endpoint performs an action on a plain GET. - **An oracle**, because a connection refused, a timeout and a well-formed error take different times and produce different failures, which maps your internal estate one probe at a time. - **Exfiltration**, if the fetched body, or the upstream error containing it, is returned to the caller or written to a log the caller can read. - **Amplification**, if the fetch happens per request rather than once and cached, so an attacker can make your server flood a third party. ## Controls, and what each actually closes | Control | What it closes | What it leaves | |---|---|---| | Allowlist of issuers you will dereference | Arbitrary destinations | Nothing, if the list is configuration rather than discovery | | Require the `https` scheme | Redirection to other protocols and cleartext fetches | Internal hosts that speak HTTPS | | Resolve the name and reject internal addresses | Internal reach by name or literal | A name that resolves differently on the second lookup | | Refuse redirects | A validated host handing you off to an internal one | Nothing, provided you refuse rather than re-validate loosely | | Cap response size and time | Amplification and resource exhaustion | Small, fast probes | | Never echo body or upstream error | Exfiltration through the response | Timing as a weaker oracle | Two of those rows deserve emphasis. **Refusing redirects** matters because a host that passes your check can answer with a redirect to one that would not; validating the first hop and then following whatever comes back is the same as not validating. And **re-resolution** matters because the address you checked and the address the connection uses can differ if the name is looked up twice - the safe pattern is to resolve once, validate the address, and connect to that address. ## A guarded fetch ```pseudocode function fetch_metadata(url, allowed_issuers): if url not in allowed_issuers: reject "issuer not allowed" if scheme of url is not "https": reject "scheme not allowed" address = resolve_once(host of url) if address is loopback, private or link-local: reject "internal address" response = http_get(address, host_header = host of url, follow_redirects = false, max_bytes = 65536, timeout_seconds = 2) if response.status is not 200: reject "unexpected status" return response.body ``` ## The judgement behind it The cheapest control is the one people skip: **do not make the fetch dynamic at all**. For a partner integration whose issuer you agreed in a contract, the endpoints belong in configuration, refreshed deliberately, with discovery used to detect drift rather than to decide where to connect. Dynamic dereferencing earns its keep in a deployment that genuinely meets parties it has never met; in one that has three known partners, it is a network-reach primitive handed to whoever can influence a string, in exchange for convenience nobody asked for.