URL-to-PDF and SSRF: how a PDF renderer becomes an attack surface
A renderer that fetches URLs can be pointed at your internal network. The attacks, the defences, and what to demand from a PDF API vendor.
A URL-to-PDF endpoint is a web browser you let strangers drive. If that browser sits inside your network, it can be asked to open http://169.254.169.254/ — cloud metadata, including credentials — or http://localhost:8080/admin, and print what it sees into a PDF the attacker then downloads.
This is server-side request forgery, and PDF renderers are among its most reliable hosts, because fetching arbitrary URLs is the advertised feature.
The attack surface
Direct. Submit an internal URL. The renderer is inside the perimeter; the attacker is not.
Redirect. Submit a public URL that responds 302 to an internal one. Validating only the URL you were given catches nothing.
DNS rebinding. A hostname that resolves to a public address when you validate it and to 127.0.0.1 a moment later when the browser connects. Time-of-check to time-of-use, in DNS form.
Subresources. Even with a validated page URL, the HTML can contain