API SSRF Security
A user-controlled URL is an SSRF question only if the server uses it dangerously.
Server-Side Request Forgery happens when a server can be induced to make an unintended request. OpenAPI can reveal URL-like inputs that deserve review, but it cannot prove dereferencing or network-control bypass.
Look at inputs the client controls.
Query parameters, headers, path values, and request-body fields named or typed like URLs, URIs, hosts, callbacks, redirects, or fetch locations can indicate a possible SSRF sink.
Do not treat every URL in the document as attacker-controlled input.
Server URLs, response schemas, documentation links, examples, and descriptions are not equivalent to request values a caller can influence.
SSRF defense is enforced by the application and network.
Verify allowlists, DNS and redirect handling, private-address blocking, metadata protection, scheme restrictions, egress policy and timeouts.
High-value destinations
Loopback, RFC1918, link-local, internal services and cloud metadata endpoints require explicit protection.
Redirect and DNS behavior
A destination safe before a redirect or DNS change can become unsafe later in the request path.
Use OpenAPI to find where dynamic verification belongs.
Dynamic testing should be authorized, bounded, and non-destructive.
Contract analysis narrows the review surface; it does not establish SSRF exploitability.