---
{
  "title": "Server-side request forgery (SSRF)",
  "summary": "SSRF occurs when an attacker influences a server to send requests to unintended destinations.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: Server Side Request Forgery Prevention",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

SSRF occurs when an attacker influences a server to send requests to unintended destinations. The server may have network access or credentials unavailable to the attacker. Protection requires validating the actual destination and controlling outbound access, not merely checking a URL's superficial appearance.

## A practical example

A link-preview service accepts public URLs. It prevents requests to internal infrastructure, treats redirects as new destination decisions, and avoids attaching privileged credentials to retrieved content. The network layer reinforces the allowed destination policy.

## What to check

Use a constrained destination allowlist where the business permits it. Account for DNS resolution, alternate address forms, redirects, supported schemes, and network egress restrictions.

## A common pitfall

A URL beginning with HTTPS is not necessarily a safe destination. Encryption protects transport; it does not decide which internal or external resource the service should contact.

## Think it through

Why recheck a redirect target?

**Answer:** The approved initial URL may redirect to an internal or otherwise prohibited destination, changing the security decision.

## The server becomes the requester

A fictional reading app fetches page titles for links saved by users. The user supplies a destination, but the application's server makes the connection. Its network position may allow it to reach administrative services that are not reachable from the user's browser. That difference in authority is what makes the feature a security boundary.

Define the intended feature first. If the app only imports resources from one trusted document provider, a narrow destination policy is feasible. A general public-web preview has more complex requirements because arbitrary hosts, redirects, and changing DNS answers are part of normal operation. In either design, the URL parser and the networking client must agree on the destination being approved.

Outbound network controls provide a second place to enforce policy. A preview worker need not have the same internal access as the main application. Keep privileged credentials out of generic fetch requests, set response-size and time limits, and consider the effect of processing returned content. Successfully contacting a permitted host does not make the response safe to execute or render.

## Model the feature with three destinations

For a paper exercise, describe a permitted document host, an unrelated public host, and a fictional internal administration host. Add a redirect from the permitted host to each of the others. State where the application re-evaluates the destination and where the network would independently block a prohibited connection.

Use an isolated mock server if demonstrating the behavior; do not probe real internal services or cloud metadata endpoints. A useful assessment report can show that the server attempted an unintended connection to a controlled endpoint without retrieving sensitive data. The repair should cover redirects and resolution behavior, not merely the original text entered into the URL field.

## Related concepts

- [[dns]]
- [[cloud-security-architecture]]
- [[input-validation]]