ReportVerse
A PDF report builder that fetches user-supplied data-source URLs server-side and embeds the response in a polished PDF. Spot the missing guardrail and use it to reach something the marketing page advertises but never intended you to see.
The Scenario
ReportVerse is a SaaS for generating branded PDF reports from "any HTTP data source — internal staging APIs, dashboards behind your firewall, or anything you can point us at." Their marketing copy says the quiet part out loud, and their engineers built exactly what was promised. Generate a few reports, read carefully, and see what the renderer is happy to bring back for you.
Lab Intel
Synopsis
A PDF-report builder is vulnerable to server-side request forgery: its renderer accepts user-supplied URLs without an IP or hostname blocklist, letting an attacker reach loopback-bound internal services and exfiltrate their HTML responses in-band through the generated PDF.
Architecture
A medium-difficulty Node.js + Express service that drives headless Chromium through Puppeteer to fetch and render a user-provided data-source URL into a polished PDF. A second Node process runs in the same container on a loopback-only port, serving an unauthenticated internal-metrics dashboard. Several hardening layers are in place and work as intended — scheme allowlist (http/https only), Chromium --disable-file-access flags, and Puppeteer request-interception on subresources — but the renderer never enforces an IP or hostname blocklist, leaving RFC-1918 and loopback addresses reachable.
Who It's For
Built for security practitioners learning server-side request forgery and the risks of putting a headless browser between an attacker-controlled URL and an internal network. You should be comfortable reading HTTP requests and responses; prior Node.js or Puppeteer experience is not required, but a working mental model of how a browser fetches and renders a page will help.
Skills You'll Practice
- Recognising SSRF surfaces in features that fetch user-supplied URLs server-side
- Reasoning about which hardening layers (scheme check, request interception) cover which threats — and which gaps they leave behind
- Enumerating internal services bound to loopback by probing ports and reading response/error behaviour differences
- Exfiltrating internal-only content in-band by piggy-backing on the same rendering pipeline a legitimate user would use
- Comparing the behaviour of headless browser navigation against a plain HTTP client for SSRF purposes
What You'll Gain
- A mental model for evaluating SSRF defences: scheme filtering and resource blocking are not substitutes for an IP/hostname blocklist
- Recognition that defence-in-depth is comforting until the layer with the actual threat coverage is missing
- Practical understanding of why loopback, RFC-1918, and cloud-metadata endpoints must be blocked at the network or fetcher boundary
- Experience treating marketing copy and feature descriptions as recon material — sometimes the bug is advertised on the homepage
- Awareness of how headless browsers (Puppeteer, Playwright) introduce new SSRF surfaces and the controls those tools do or do not give you