A headless browser loads more than the URL you submit. Scripts, images, frames and redirects can send additional requests. For a service rendering untrusted pages, controlling those destinations is part of preventing server-side request forgery, or SSRF.
Validate destinations throughout the request
Validate the URL scheme and the addresses a hostname resolves to. Restrict access to private networks, loopback and cloud metadata endpoints. An allowed starting URL does not make a redirect destination safe: disable redirects or validate each destination before following it.
DNS answers can change between validation and connection. Application checks therefore need a network boundary that limits what the rendering process can reach. The OWASP SSRF prevention guide explains the URL, DNS and network controls involved.
Keep rendering separate from application credentials
A rendering process should receive only what it needs for the capture. Database passwords, billing credentials and application signing keys do not belong in the environment that executes an unfamiliar page.
Verify network restrictions with test pages that attempt allowed and forbidden connections. A successful screenshot proves that rendering works; it does not establish which other destinations were reachable.
Handle refusals in your integration
domscout refuses private-address targets and rechecks redirects. If a target is refused, inspect the response code before retrying. A platform refusal such as BROWSER_ISOLATION_REQUIRED or BROWSER_EXECUTION_DENIED has no upgrade_url; changing plans does not clear it.
Use GET /credits to check current account capabilities without consuming credits. If a legitimate public target is blocked, report the URL and response code through `POST /feedback`.
For request examples, see the screenshot API guide, the screenshot product page and the API docs.