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 the server dereferences them or bypasses network controls.
Static signal
Look at inputs the client controls.
Query parameters, headers, path values, and request-body fields named or typed like URLs, URIs, hosts, callback destinations, redirect targets, or fetch locations can indicate a possible SSRF sink. The HTTP method alone is not enough to decide relevance.
Avoid false positives
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. A useful static rule limits itself to reachable input surfaces and keeps the finding wording conditional.
Runtime protections
SSRF defense is enforced by the application and network.
Verify destination allowlists, DNS and redirect handling, private and link-local address blocking, cloud metadata protection, scheme restrictions, egress policy, timeouts, and whether the server normalizes or re-resolves destinations safely.
High-value destinations
Loopback, RFC1918 networks, link-local ranges, internal services, and cloud metadata endpoints require explicit protection.
Redirect and DNS behavior
A destination that is safe before a redirect or DNS change can become unsafe later in the request path.
Review workflow
Use OpenAPI to find where dynamic verification belongs.
Contract analysis can narrow a large API to operations with caller-controlled destination-like input. Dynamic testing should then be authorized, bounded, and non-destructive.
OpenAPI Security scanner → · Security checklist → · API security pillar →