SSRF Beyond the Fetch: Renderers, Hooks, Rebinding
DNS rebinding, PDF generators, headless browsers, webhook senders and URL preview crawlers: server-side requests nobody wrote on purpose.
Most SSRF in real applications is not a URL parameter. It is a renderer, a crawler or a hook that fetches something on the server’s behalf and inherits its network position.
DNS Rebinding
DNS rebinding exploits a simple difference: the browser trusts the hostname for same-origin while DNS resolution may later change the IP. A controlled domain first resolves to an attacker IP and later to localhost or a private address with low TTL. JavaScript loaded from the first response remains in the same logical origin and then tries to communicate with the new IP. I use a lab with my own authoritative DNS and a disposable internal service, and I measure browser caching before testing local administration. Browsers, DNS pinning, HTTPS and Host validation reduce viability. Local APIs should authenticate rather than relying only on network origin.
1
2
lab.example. 30 IN A 203.0.113.10 ; first response, passes the allowlist
lab.example. 30 IN A 127.0.0.1 ; second response, after the TTL expires
PDF Generators as SSRF
Generating PDF from HTML often launches a browser or renderer inside the server. Images and stylesheets become server-side requests. wkhtmltopdf, Chromium, Puppeteer and custom engines load external resources while rendering. Controlled HTML may point images, iframes, CSS or fonts at localhost, intranet systems or cloud metadata depending on renderer restrictions. I start with an OAST URL in an image and verify interaction before testing an internal destination. Even when fetched content never appears in the PDF, timing and OAST can prove Blind SSRF. Sandboxing and network egress controls still matter.
1
<img src="https://oast.example/pdf-test">
Headless Browsers
When Chromium runs in the backend, controlled HTML stops targeting only the user and starts executing near server network access and credentials. Puppeteer and Playwright automate real browsers. Screenshot services, crawlers and preview systems commonly use these components. JavaScript may send requests, read DOM state, use cookies configured by the job and interact with services reachable by the host. I determine whether JavaScript is enabled, which cookies or headers the renderer receives and what network egress it has. The browser sandbox protects a kernel boundary, not application authorization. An authenticated headless browser can still access whatever its session permits.
1
<script>fetch('https://oast.example/headless')</script>
Webhook Security
A webhook looks like an asynchronous POST until you realize it crosses two organizations and often changes state without a user watching. A webhook receiver needs sender authentication through signatures, shared secrets or mTLS. Timestamps and nonces help prevent replay. The webhook sender also becomes SSRF when arbitrary callback URLs are allowed and requests originate from internal infrastructure. I test receiver and sender separately: signatures, canonicalization, replay, redirects and destination allowlists. Signing a parsed body may break canonicalization. Verification should use the exact bytes defined by the provider.
1
2
X-Signature: sha256=...
X-Timestamp: 1790000000
URL Preview Services
A link preview feature must visit the URL to fetch titles, images and metadata. That is already a server-side request primitive by design. Preview bots follow redirects, resolve DNS and parse HTML. Some also load images and OpenGraph resources. The surface includes SSRF, oversized content, parser bugs and token leakage when the crawler sends internal headers. I start with a controlled domain and record method, headers, source IP, redirect behavior and secondary requests. Filtering only the initial URL does not protect redirects or embedded resources. Validation must follow every final connection.
1
<meta property="og:image" content="https://oast.example/image">