Modern serverless and edge applications make outbound HTTP requests constantly — fetching user-provided URLs, handling webhooks, validating OAuth redirects, proxying APIs, generating previews, and more. On Vercel, these patterns are extremely common in Serverless Functions, Edge Functions, and Next.js API routes.
Every time your application makes a request on behalf of a user, you open the door to **Server-Side Request Forgery (SSRF)**.
This post introduces **dssrf**, a deterministic outbound‑request validation library for Node.js that blocks SSRF by validating the *actual* destination of a request before any connection is made.
Why SSRF Matters on Vercel
Vercel does **not** expose a cloud metadata interface like AWS, GCP, or Azure. However, SSRF is still highly relevant because Vercel applications frequently fetch **user-controlled URLs** in:
- Next.js API routes
- Serverless Functions
- Edge Functions
- URL preview endpoints
- webhook handlers
- OAuth redirect validators
- proxy endpoints
If the destination isn’t validated, attackers can abuse redirect chains, DNS rebinding, or malformed hostnames to reach unintended internal or private network targets.
Why Traditional Defenses Fail
Most SSRF mitigations rely on:
- allowlists
- blocklists
- regex filters
- hostname checks
- naive URL parsing
These approaches break when attackers use:
- DNS rebinding
- redirect chains
- IPv6-mapped IPv4
- octal/hex IP formats
- malformed hostnames
- CDN IP rotation
To prevent SSRF reliably, you must validate **where the request will actually go**, not where the user claims it will go.
The Deterministic Approach
dssrf implements a deterministic, safe‑by‑construction validation pipeline:
- Normalize the URL
- Resolve DNS
- Classify the resulting IP
- Block internal, private, or link‑local ranges
- Follow redirects safely
- Re-validate every hop
- Only then perform the request
This eliminates entire categories of SSRF attacks.
Links:
[Github](https://github.com/HackingRepo/dssrf-js)
[NPM](dssrf - npm)