Server-side request forgery (SSRF)

Server-side request forgery arises whenever an application fetches a URL that a user influenced. A webhook registration, an avatar imported from a link, a document converter, a preview generator that renders whatever address it is handed — each of these turns your server into a proxy operating on somebody else’s instructions. The request then originates from a machine sitting behind the perimeter, holding whatever network position and credentials that machine has been granted.

That position is the entire prize. Internal admin panels with no authentication because they were never meant to be reachable, databases bound to a private interface, and cloud metadata endpoints that hand out short-lived credentials to anything able to ask are all suddenly addressable. The flaw is one of the few where the severity depends less on the code than on the architecture around it, which is why the same defect scores differently on two systems and why a fix limited to the input validation frequently misses the point.

Where the controls belong

• An allow-list of destinations, resolved and checked after DNS resolution rather than before, because a hostname an attacker controls can resolve to an internal address at the moment of the request.
• Blocking redirects, or re-validating every hop, since a permitted host that answers with a redirect to a private range defeats a check performed only on the original URL.
• Egress rules on the workload itself, so the service can only reach the destinations it genuinely needs. This is the control that survives a validation bug.
• Requiring a session token on the cloud metadata service, which converts the most valuable target into one that a blind fetch cannot reach.

Blind SSRF, where no response body is returned to the attacker, is still exploitable: timing, error differences and side effects on internal services leak the information the response would have.