Server-Side Request Forgery

Why it is folded into Broken Access Control in 2025

The OWASP overview chapter noted this reclassification, and understanding it is a good test of understanding the attack. SSRF is, at bottom, a request reaching a resource it should not be allowed to reach: the server accesses an internal service that the request should not have been authorised to reach. That is an access-control failure, the request crosses a boundary it should not, so grouping it under Broken Access Control in 2025 reflects that SSRF is fundamentally about a request reaching an unauthorised destination.

The reclassification does not change the attack or its defences; it changes the heading, and it teaches that categories are ways of organising, not fixed truths, which the overview chapter emphasised.

The defences

The fixes restrict where the server may make requests and limit what it can reach:

Validate and restrict the destination. Do not let the user freely specify the URL the server fetches. Where the server must fetch a user-influenced URL:

• Use an allow-list of permitted destinations (specific domains or addresses the feature legitimately needs), rejecting anything else. This is the strongest fix, mirroring the directory-traversal chapter's allow-list approach: constrain to known-good rather than trying to block known-bad.
• Block internal and reserved addresses: reject requests to internal address ranges, the local machine, and the cloud metadata address. This is a deny-list and is weaker than an allow-list (attackers find encodings and redirects to reach blocked addresses, the recurring filtering-is-fragile lesson), so it supplements rather than replaces the allow-list.
• Do not follow redirects to unauthorised destinations, since a redirect can send an allow-listed request onward to a blocked one.

Network controls. Limit what the server can reach, so that even a successful SSRF reaches little:

• Segment the network so the application server cannot reach sensitive internal services it does not need (least privilege for network reach), which is the segmentation principle applied.
• Protect the cloud metadata service: cloud platforms provide hardened versions of the metadata service that resist SSRF, and these should be used; restrict the server's access to it.
• Egress filtering from the server, so it cannot make arbitrary outbound requests, connecting to the amplification and Log4Shell chapters' egress point.

The combination: allow-list the destinations, block internal and metadata addresses as a supplement, do not follow redirects, and use network segmentation and egress controls so a successful SSRF reaches little. The primary fix is constraining the destination; the network controls are defence in depth.

A worked example, framed defensively

An assessor tests an application feature that fetches a user-supplied URL (an "import from URL" function), using benign internal test addresses.

• Supplying an internal address causes the server to fetch it and return the response, revealing an internal service not exposed to the internet. SSRF (in-band): the server is used as a proxy to reach the internal network. Fix: allow-list permitted destinations; block internal addresses.
• Supplying the cloud metadata address returns the server's cloud credentials. The most severe finding: SSRF to the metadata service. Fix: use the hardened metadata service, restrict access, and allow-list destinations.
• The feature follows redirects, so an allow-listed URL redirecting to an internal one is fetched. Finding: redirect bypass. Fix: do not follow redirects to unauthorised destinations.
• The application server can reach broad internal ranges. Finding: no segmentation, so a successful SSRF reaches much. Fix: segment and apply egress filtering.

The report explains that SSRF turns the server into a proxy for the attacker to reach the internal network, that the cloud-metadata case is the severe one, and that it is now classified under Broken Access Control because it is a request reaching an unauthorised destination. The assessor uses benign internal test targets to demonstrate the flaw, not to access real internal systems beyond what proves it.

What beginners get wrong

• Thinking the attacker fetches the URL. The server fetches it, from the server's network position, which is why the attacker reaches internal systems they could not reach directly.
• Missing the cloud-metadata case. SSRF to the metadata service can retrieve the server's cloud credentials, often the most severe outcome, and it is why SSRF rose with cloud adoption.
• Relying on a deny-list of internal addresses. Attackers use encodings and redirects to reach blocked addresses; use an allow-list of permitted destinations as the primary fix.
• Following redirects. An allow-listed URL can redirect to a blocked internal one; do not follow redirects to unauthorised destinations.
• Ignoring network controls. Segmentation and egress filtering limit what a successful SSRF reaches; they are defence in depth.
• Thinking the reclassification changes the attack. Folding SSRF into Broken Access Control is a heading change reflecting that it is a request reaching an unauthorised destination; the attack and defences are unchanged.

Quick revision

• SSRF: the application is induced to make a server-side request to an attacker-chosen URL, so the server fetches it from its own network position, reaching internal services, the server's local services, and the cloud metadata service (which can yield the server's credentials) that the attacker cannot reach directly. The server becomes the attacker's proxy.
• Blind SSRF: the request is made but the response is not returned to the attacker; less powerful, still dangerous.
• Reclassified from its own 2021 category into Broken Access Control in 2025, because it is fundamentally a request reaching an unauthorised destination.
• Defences: allow-list permitted destinations (primary), block internal and metadata addresses (supplement, weaker), do not follow redirects, and segment the network and filter egress so a successful SSRF reaches little; protect the cloud metadata service.

Test yourself

1. What is server-side request forgery, and why is it powerful?

It is an attack in which an application is induced to make a request to a URL the attacker chose, so the server fetches it on the attacker's behalf. It is powerful because the server sits inside the organisation's network and can reach things the attacker cannot: internal services and administrative interfaces not exposed to the internet, the server's own local services, and the cloud metadata service, so the attacker uses the server as a proxy to reach the internal network.

1. Why is the cloud metadata case particularly severe?

Because cloud platforms expose to a server a special internal address that returns the server's configuration and often its credentials, and an SSRF that reaches this address can retrieve those cloud credentials. That is a severe escalation, since it hands the attacker the server's identity in the cloud environment, and it is why SSRF rose to prominence as applications moved to the cloud.

1. Why is SSRF classified under Broken Access Control in the 2025 edition?

Because it is fundamentally a request reaching a resource it should not be allowed to reach: the server accesses an internal destination the request should not have been authorised to reach, which is an access-control failure. Grouping it under Broken Access Control reflects this, and the reclassification changes the heading, not the attack or its defences, illustrating that OWASP categories are ways of organising rather than fixed truths.

1. Why is an allow-list a better defence than blocking internal addresses?

Because blocking internal addresses is a deny-list, and attackers can reach blocked addresses using alternative encodings, address formats, or redirects, so it is fragile in the same way filtering a dangerous pattern is fragile. An allow-list of the specific destinations the feature legitimately needs constrains the server to known-good targets and rejects everything else, which is robust, with the internal-address blocking used only as a supplement.

1. What network controls limit the impact of a successful SSRF, and to what principle do they correspond?

Segmenting the network so the application server cannot reach sensitive internal services it does not need, using the hardened cloud metadata service and restricting access to it, and applying egress filtering so the server cannot make arbitrary outbound requests. These correspond to least privilege and segmentation applied to the server's network reach, ensuring that even a successful SSRF reaches little, as defence in depth behind the primary fix of constraining the destination.