Validator endpoint performs server-side request to user-supplied URL (confirmed SSRF behavior)

Summary

The Swagger Validator endpoint performs server-side HTTP GET requests to URLs fully controlled by the user via the url query parameter.
This behavior has been directly observed and confirmed using a real external endpoint (webhook.site).

Proof of behavior (real example)

Request made by the browser:

GET /validator?url=https://webhook.site/80b7dee8-9bd0-4ea6-8461-5cedba30a7e5 HTTP/2
Host: validator.swagger.io

As a result of this request, the following server-side request was received on webhook.site:

Source IP: 52.87.88.179

Geo: Ashburn, Virginia, USA (AWS)

User-Agent: swagger-validator

Method: GET

Response size: 0 bytes

This request was not sent by the client browser, but by Swagger Validator infrastructure.

Evidence

The incoming request appears in webhook.site logs

The User-Agent is swagger-validator

The source IP belongs to AWS

The request occurs immediately after accessing the validator URL

These facts confirm that the validator backend initiates outbound HTTP requests based on user input.

Why this is SSRF

User controls the target URL

Server performs the request

Request originates from backend infrastructure

No client-side CORS or browser networking involved

This matches the definition of Server-Side Request Forgery (SSRF).

Impact

This allows:

External network interaction from Swagger infrastructure

Reachability testing of arbitrary hosts

Potential abuse if internal or restricted networks are reachable

Expected behavior

Clear documentation warning that URLs are fetched server-side
or

Restrictions on reachable targets (e.g., IP filtering / allowlists)

Notes

This report is based on direct observation, not assumption or speculation.

Start at the validator endpoint's handling of the url query parameter and trace where the server-side GET is initiated. Review whether the project will document server-side fetching or restrict reachable targets, then confirm the selected approach addresses the reported SSRF behavior. Done means the validator no longer permits the reported unsafe behavior, with the relevant behavior covered by existing project checks.