Parsing a URL only proves that it has valid syntax. A server-side Puppeteer browser may visit internal addresses, follow redirects, and load images, scripts, frames, or other subresources from additional hosts. Restrict destinations and protocols before navigation, inspect each browser request, and run the browser in a network-isolated environment with resource limits.
This guide covers check 04: Input validation and error handling; check 06: Performance and scalability in the Zenveus Production Readiness Standard.
For builders
A headless browser loads more than the first URL you give it. A public page can redirect it or make it fetch images and frames from private destinations. Isolate the browser’s network and check every request, then prove the internal test service received nothing.
A scoped repair request
Use this prompt in Lovable, Cursor, Replit, or Claude Code with the relevant server files available.
Audit my Cursor-generated Puppeteer scraper for SSRF across navigation, redirects, frames, images, scripts, and DNS changes. Add per-request validation plus isolated network egress controls, byte limits, timeouts, concurrency limits, and guaranteed browser cleanup. Work on a branch with synthetic data and mocked external services. Show the smallest diff, identify required adapters and deployment settings, and add allowed and denied tests that prove side effects cannot happen before checks pass. Do not disable security checks to make a test pass.The same failure may appear as
Find the failure layer
Each check removes a class of causes. Keep the first failing result, its timestamp, and the production log beside it.
Find the request field passed to `page.goto` or equivalent and record checks performed before a browser is launched.
Inspect top-level navigation, redirects, frames, scripts, images, and fetch/XHR requests. A safe landing URL can load an unsafe subresource.
Use a fake internal service and disposable browser container. Verify that direct private addresses, redirects, and pages embedding internal resources are denied before contact. Never test against a live third-party target.
Set timeouts, maximum pages, response bytes, and concurrent sessions. Close the browser even after errors.
Ranked diagnosis
The server accepts any URL that parses before calling the browser.
Frames, scripts, and images reach hosts not present in the initial URL.
Headless navigation can access internal addresses if egress is unrestricted.
A page can keep a browser busy or consume large responses.
Step-by-step repair
Edit app/api/scrape/route.ts and the browser creation helper. Place the browser worker behind an outbound network policy; request interception is an additional application check.
Production safety ruleNever disable access controls, expose service keys, or add wildcard CORS as a routine shortcut.
For a fixed-site scraper, allow exact HTTPS hosts and the required port. Reject userinfo and unexpected protocols. If the product accepts arbitrary public sites, use an outbound gateway that validates and constrains the connection destination.
Enable interception before navigation. Apply the policy to main requests, redirected requests, frames, scripts, and images. Check isInterceptResolutionHandled before resolving a request when multiple listeners exist.
Deny loopback, private, link-local, metadata, and other internal destinations for IPv4 and IPv6 at network level. Use a fresh browser context, no ambient credentials, and a patched browser with its sandbox enabled.
Set a navigation timeout and worker-level memory, concurrency, response-byte, and total-duration limits. Close the browser in finally. Test direct navigation, redirects, and embedded resources against disposable fixtures.
Implementation example
const allowedHosts = new Set(['docs.example.com']);
await page.setRequestInterception(true);
page.on('request', request => {
if (request.isInterceptResolutionHandled()) return;
let allowed = false;
try {
const u = new URL(request.url());
allowed = u.protocol === 'https:' && allowedHosts.has(u.hostname)
&& !u.username && !u.password && (!u.port || u.port === '443');
} catch {}
if (allowed) void request.continue();
else void request.abort('blockedbyclient');
});
try {
await page.goto(targetUrl, { timeout: 10000, waitUntil: 'domcontentloaded' });
} finally { await browser.close(); }Replace docs.example.com with the intended host and validate targetUrl before navigation. Host checks cannot prevent DNS rebinding by themselves; enforce connection-level egress restrictions. The snippet assumes an already-created page and browser.
Prove the repair
Run these checks with synthetic data in your test environment, then repeat the relevant acceptance checks after deployment.
When the built-in AI fix makes it worse
Pause generated changes, restore a known working branch, and capture one failing request with its logs. Change one layer and rerun the allowed and denied checks before proceeding.
Engineering handoff
We trace one production request through the complete path, isolate the failing boundary, and leave behind evidence your team can repeat.
Top-level navigation, redirects, frames, images, and scripts.
Worker egress policy, resolved destinations, and private-network denial.
Timeouts, response limits, concurrency, and browser shutdown on errors.
Approved-page results and zero contact with the mock internal service.
Typical repair pattern
A disposable browser reaches approved pages while fake internal endpoints see no direct, redirected, or embedded requests.
Before the next release
Clear answers
No. It validates syntax, not the destination's trust level or what the page later loads.
A user-provided AI key changes provider billing exposure. It does not constrain the server-side browser's network access.
No. Redirects, iframes, scripts, and images can reach additional destinations.
Run the verification checks on this page against your test environment, then repeat the relevant checks after deployment. Example code needs your app's authentication, data model, and configuration; reading the guide alone does not verify your deployment.
Related symptoms
Official documentation and library references
Free next step
The free tool helps you inspect this symptom. Its result does not establish whether the whole app is production ready.
The Verdict
We can see the symptom from here. What we cannot tell you from outside is whether it is contained or structural. A scanner collects evidence. A named senior engineer makes the decision. For $299, a named senior engineer reads your code and signs a written Verdict against the nine checks in the Zenveus Production Readiness Standard. The 48-hour clock begins when the required access and context are available. If the report does not give your developer a list they can act on, you do not pay.
The 48-hour clock starts when the required access and context are available.
Free decision aid
Get a senior view of the constraint, the evidence you have, and the next decision that removes the most risk.
No email required for this decision aid. Dismiss once and this popup stays closed for the session.