When a Next.js API route passes a caller-supplied URL straight to server-side `fetch`, the caller may be able to make the server contact destinations that their own browser cannot reach. Replace the arbitrary URL with a named, configured upstream action. Allow only required methods and headers, and enforce destination and egress checks before every outbound request.
This guide covers check 04: Input validation and error handling; check 06: Performance and scalability in the Zenveus Production Readiness Standard.
For builders
A proxy lets your server fetch another website for the app. If visitors choose any destination, they may make it contact systems that should be private. Replace arbitrary URLs with approved actions and verify that blocked destinations receive no request.
A scoped repair request
Use this prompt in Lovable, Cursor, Replit, or Claude Code with the relevant server files available.
Audit my v0 Next.js proxy route for SSRF. Replace client-selected URLs with server-defined upstream actions; check redirects, DNS resolution, response size, timeouts, and deployment egress policy. 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 every place the request body, query, or header can set the outbound destination. Record any user-controlled method and forwarded headers.
Determine whether the route is deployed, who can call it, what networks the server can reach, and whether a gateway or egress firewall constrains it. Source code alone does not establish live reachability.
Use a permitted mock API and a fake internal HTTP endpoint. Confirm that private, loopback, link-local, metadata-style, redirected, and re-resolved destinations are rejected before a request reaches the fake internal service. Do not probe live third-party systems.
Limit time, bytes, and content types. Do not relay arbitrary upstream errors, credentials, or headers to the caller.
Ranked diagnosis
The client provides a full URL instead of selecting a server-defined action.
A valid URL can still resolve or redirect to an internal address.
The server can reach destinations unrelated to the intended product integration.
Caller-selected methods, headers, or response bodies make the proxy more powerful than required.
Step-by-step repair
Replace the handler in app/api/proxy/route.ts that accepts a complete URL. If the integration needs arbitrary websites, use a dedicated outbound gateway rather than this fixed-upstream pattern.
Production safety ruleNever disable access controls, expose service keys, or add wildcard CORS as a routine shortcut.
Remove client-supplied destination, method, and forwarding headers. Map an operation such as health to one literal HTTPS endpoint you control or trust. Fail deployment until that endpoint is configured.
Set redirect to error and use a request timeout. Forward only server-selected headers. For larger responses, read a stream with a byte ceiling; a Content-Length check alone is insufficient.
Restrict outbound traffic to the required upstream. If URLs remain dynamic, validate all resolved IPv4 and IPv6 addresses and enforce the same policy when connecting; a separate DNS check followed by ordinary fetch leaves a rebinding gap.
Test one permitted destination, an unknown action, and a permitted endpoint that redirects. Confirm no request reaches the redirect target. Do not test cloud metadata addresses on a production host.
Implementation example
const HEALTH_URL = 'https://api.example.com/health';
export async function POST(request: Request) {
const body = await request.json().catch(() => null);
if (!body || body.action !== 'health') {
return new Response('Unsupported action', { status: 400 });
}
try {
const upstream = await fetch(HEALTH_URL, {
method: 'GET', redirect: 'error', cache: 'no-store',
signal: AbortSignal.timeout(5000)
});
return Response.json({ healthy: upstream.ok });
} catch {
return new Response('Upstream unavailable', { status: 502 });
}
}Replace api.example.com with your actual fixed upstream. This deliberately returns a status result instead of relaying arbitrary content. Add caller authorization where required and an egress policy; this is not an arbitrary-URL sanitizer.
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.
Server-owned action maps, credentials, methods, and response handling.
Resolved addresses, DNS changes, redirects, and every outbound hop.
Worker egress rules and internal or metadata-network reachability.
Mock internal-service logs alongside allowed upstream requests.
Typical repair pattern
A permitted mock API works while private, redirected, and arbitrary destinations fail before network contact.
Before the next release
Clear answers
No. DNS, redirects, alternate address forms, and network reachability still matter.
No. The outbound request originates on the server, outside browser CORS enforcement.
Prefer a short allowlist of named upstream services plus network isolation. A small blacklist misses other internal addresses and redirect paths.
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.