# SSRF, File Fetch, and Parser Abuse Review Guide

> **Intro:** Serious web issues are not only XSS and SQLi. They also happen when a trusted server fetches attacker-influenced URLs, parses attacker-controlled files, or reaches internal systems the browser never could.
>
> **What this page includes**
>
> * a practical SSRF review model
> * upload, import, and parser features that become server-side fetch surfaces
> * cloud and metadata-service implications
> * release questions for real product teams

## A simple mental model

SSRF is often:

* a **privilege pivot** because the attacker borrows the server’s network reachability;
* an **identity pivot** because the attacker borrows the server’s attached credentials;
* a **parser pivot** because a worker interprets hostile content.

## Typical entry points

Look for:

* import from URL;
* image fetch or avatar fetch;
* preview or screenshot generation;
* URL unfurling and metadata enrichment;
* PDF/HTML rendering;
* webhook test buttons and callback verifiers.

Also review indirect inputs such as redirects, XML or SVG with external references, and parsers that perform secondary fetches.

## Dangerous targets

A backend fetcher can often reach:

* metadata services and instance identity endpoints;
* private RFC1918 ranges;
* internal admin panels;
* service mesh and cluster-internal DNS names;
* local loopback services.

## Defensive architecture patterns

If the business truly needs server-side fetching, centralize it:

* dedicated service or worker pool;
* narrow outbound rules;
* explicit protocol allow-list;
* strict redirect handling;
* response size and type limits;
* separate identity from the main application where possible.

## File upload meets SSRF and parser abuse

Uploaded content can cause secondary network activity or dangerous parser behavior.

High-risk examples:

* SVG with external references or embedded active content;
* XML formats with entity expansion or external resolution;
* office documents or HTML uploads that trigger rendering engines;
* archives that hide nested file types or trigger downstream processors.

A safer design bias is: store first, process later; quarantine before rendering; strip or disable active features where practical; isolate preview and conversion workers from privileged networks.

## Review questions

* Can the user influence any fetched URL or hostname directly or indirectly?
* What can this worker reach on the network?
* What credentials or workload identity does it inherit?
* Can it contact metadata or admin services?
* Which libraries parse the uploaded or fetched content?

## Release criteria

* [ ] attacker-influenced fetch surfaces inventoried
* [ ] egress and protocol allow-lists defined for fetchers
* [ ] redirect, size, MIME, and timeout behavior reviewed
* [ ] metadata-service exposure reviewed for worker nodes and containers
* [ ] preview and conversion workers isolated from privileged networks

## Related pages

* [Web Application Security Review and Architecture Playbook](/application-security-and-secure-sdlc/index-1/web-application-security-review-and-architecture-playbook.md)
* [File Upload, Download, and Browser Rendering Risks](https://github.com/D3One/Product-Security-Gitbook/blob/main/18-frontend-and-browser-security/file-upload-download-and-browser-rendering-risks.md)
* [Cloud Security Across AWS, Azure, and GCP](/cloud-kubernetes-and-infrastructure-security/index/cloud-security-across-aws-azure-and-gcp.md)

***

*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/application-security-and-secure-sdlc/index-1/ssrf-file-fetch-and-parser-abuse.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.