🌐 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

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