SSRF Explained: How URL Fetching Exposes Internal Services

CyberInsights Today · Educational bulletin
By Harpreet Singh Virdi, CISSP, CCSP · November 5, 2026
References checked on November 5, 2026.

Your application can fetch an image, preview a link or send a webhook. Each feature lets data from a user influence a request made by your server. The security question is which destinations that server is permitted to reach.

What server-side request forgery means

Server-side request forgery, or SSRF, occurs when an attacker steers a server's request toward an unintended resource. The server may have access to internal services that the person making the original request cannot reach directly. URL import features and callbacks are common places to investigate. OWASP SSRF overview.

This bulletin explains a vulnerability class. Individual implementations have their own affected versions, patches and exploitation evidence. Assess the actual feature before assigning a severity score.

Follow a fictional image importer

A bookshop lets a publisher submit an image URL. A background worker downloads it and stores a thumbnail. The intended behaviour is a request to the publisher's public image service. An unsafe implementation allows the submitted URL to select a different destination, including a service reachable only from the worker's network.

Conceptual threat path

User-controlled destination

↓

Application worker makes the request

↓

Unintended service reachable from the worker

Fictional example. The trust boundary is crossed when user input selects what the server contacts.

Why impact varies

Read access can disclose internal responses. Requests that change state can affect a service behind the application. Impact depends on the destination, authentication requirements, permitted methods and whether the response reaches the user. OWASP describes internal resource access and the possibility of reading or updating resources through the server. OWASP impact description.

Assessment. Record what the worker can access and which identity it uses. A thumbnail worker with narrowly restricted network access presents a different risk from a worker that can contact administrative services. Build the prioritisation decision from this inventory.

Design the destination policy

Where the business needs a fixed group of destinations, use an explicit allowlist and construct requests from trusted configuration. For features requiring arbitrary public destinations, validate the resolved addresses and enforce connection-time restrictions. Cover IPv4, IPv6, redirects and retries. Restrict the worker's network access as a second layer. These principles follow OWASP's application and network guidance. OWASP prevention cheat sheet.

Write the requirement before selecting a validation library. For our bookshop, a publisher ID could select an approved endpoint stored by the application. If users must supply complete URLs, the team needs to document permitted schemes, destinations, ports and redirect behaviour.

Review DNS and redirects together

DNS maps a hostname to an address. The address checked during validation must remain the address authorised for the connection. A separate unchecked lookup can change the destination. OWASP also warns about disagreement between URL parsers and recommends rejecting inconsistent interpretations. OWASP destination validation.

Ask the developer to trace one request from input to socket connection. Identify every parser, resolver, proxy and redirect. Put the answer in the feature's design record. This often reveals gaps hidden by a short statement such as “URL validation enabled.”

Contain a risky feature

If the team discovers an unrestricted importer, assign an owner and consider disabling the feature or restricting it to approved destinations while the fix is developed. Choose a control the operator can verify. Record business impact, expiry and the permanent remediation task.

Defensive review workflow

1. List URL-driven features and owners.
2. Define the permitted destinations.
3. Trace validation through to the actual connection.
4. Restrict worker network access.
5. Test permitted and rejected flows in an authorised lab.
6. Monitor destination decisions in production.

Instructor's checklist for the fictional bookshop. Apply it to each fetch feature independently.

Verification and investigation

Use controlled test services in an isolated lab. Confirm that approved destinations work, prohibited destinations fail, and redirect or DNS changes do not escape the policy. Record expected and observed outcomes. Repeat tests when the HTTP client, resolver or proxy changes.

Log a request correlation ID, the feature, the destination decision and the worker identity. Retain enough information to join application events with outbound network logs. Avoid storing authentication tokens or full sensitive URLs. Investigate unexpected internal destinations or repeated rejected requests in context.

For the next design review, ask for one diagram showing where the fetch worker can connect. Then compare that diagram with the implemented destination policy and an authorised test record.

References

• OWASP SSRF overview explains the vulnerability class and impact.
• OWASP prevention cheat sheet covers destination validation and network controls.

Independent educational bulletin. The fictional scenario and checklist were not executed as a lab. See our editorial disclosure.