DEV Community: Callie Schneider

Your CORS proxy is an SSRF engine: how to harden a URL fetcher

Callie Schneider — Thu, 02 Jul 2026 10:56:49 +0000

I build and run Abundance APIs, a catalog of small utility APIs. This is a writeup of the security design behind the CORS proxy — the part I'd want reviewed. Disclosure: the proxy in the examples is mine; free tier, no signup.

A CORS proxy sounds trivial: take a url param, fetch it server-side, return the body with Access-Control-Allow-Origin: *. In reality a naive version is a gift to attackers — it's a Server-Side Request Forgery (SSRF) engine running on your infrastructure, and it will happily fetch http://169.254.169.254/latest/meta-data/ (cloud credentials) or http://10.0.0.5/internal-admin on your behalf.

Here's how the proxy is actually hardened. None of these steps are optional.

1. Scheme + host allow-listing

Only http/https. Reject everything else outright — file://, gopher://, ftp://, data: are all SSRF vectors or worse. Then resolve the hostname and reject the request if it points anywhere private.

2. Block every private/reserved IP range

The obvious one is 127.0.0.1, but the real list is long:

Loopback (127.0.0.0/8, ::1)
Link-local incl. the cloud metadata address 169.254.169.254
RFC1918 (10/8, 172.16/12, 192.168/16)
CGNAT (100.64/10)
Multicast, IPv6 ULA (fc00::/7), IPv6 link-local (fe80::/10)
IPv4-mapped IPv6 (::ffff:10.0.0.1) — easy to forget, trivially bypasses a naive IPv4-only check

3. Defeat DNS rebinding (the step most proxies skip)

Here's the subtle attack. You validate evil.com → resolves to 1.2.3.4 (public, looks fine) → then you call fetch(), which resolves the hostname again, and this time it returns 169.254.169.254. This is a TOCTOU (time-of-check-to-time-of-use) gap: the DNS answer changed between your check and the actual connection.

The fix is to resolve once, validate that specific IP, then pin the connection to it so the fetch can't re-resolve to something else. With Node's undici you do this with a custom lookup:

import { Agent } from "undici";
import dns from "node:dns/promises";

async function resolvePublicIp(hostname) {
  const { address } = (await dns.lookup(hostname))[0] ?? {};
  if (!address || isPrivateIp(address)) {
    throw new Error("Blocked: resolves to a private or reserved IP");
  }
  return address;
}

// Pin the validated IP so the actual socket can't re-resolve elsewhere.
const agent = new Agent({
  connect: {
    lookup: (hostname, opts, cb) => {
      resolvePublicIp(hostname)
        .then((ip) => cb(null, ip, opts.family === 6 ? 6 : 4))
        .catch(cb);
    },
  },
});

4. Re-validate every redirect hop

https://evil.com/start returns 302 → http://169.254.169.254/. If you follow redirects automatically, the library will happily chase it — straight past your original check. So: follow redirects manually, and run the full IP validation again on every Location before each hop.

let url = startUrl, hops = 0;
while (hops++ < MAX_REDIRECTS) {
  await resolvePublicIp(new URL(url).hostname); // re-check each hop
  const res = await fetch(url, { dispatcher: agent, redirect: "manual" });
  if (res.status >= 300 && res.status < 400 && res.headers.get("location")) {
    url = new URL(res.headers.get("location"), url).toString();
    continue;
  }
  return res;
}

5. Bound everything

An open fetcher is also a DoS amplifier and a memory bomb. Cap it:

Timeout on the upstream request (e.g. 15s)
Max response size — stream and abort past the cap (e.g. 10 MB), don't buffer unbounded
Max redirects (e.g. 5)

Testing it

The bugs here are the ones that pass a happy-path test and fail in the wild. I verify against: loopback, each RFC1918 range, the cloud metadata IP, IPv4-mapped IPv6, and — the important one — a real hostname that resolves to loopback (localtest.me resolves to 127.0.0.1), which is exactly what catches a validator that checks the string instead of the resolved IP.

Takeaway

If you're building anything that fetches a user-supplied URL server-side — a proxy, a webhook tester, a link-preview/OG scraper, an avatar-uploader-by-URL — you're building an SSRF surface whether you meant to or not. Resolve once, validate the IP, pin the connection, re-check every redirect, and bound the whole thing.

I run this as a hosted CORS proxy + link-metadata/header-inspector API if you'd rather not maintain it yourself — abundanceapis.com, with a free in-browser tester (no signup). But mostly: if you've got a URL-fetching endpoint in prod, go check how it handles 169.254.169.254 right now.

Email Validation in One API Call: Syntax, MX, Disposable, Typos

Callie Schneider — Thu, 02 Jul 2026 07:21:06 +0000

Canonical version on our guides page. Disclosure: I built the API used in the examples — it has a permanent free tier.

Why form regex isn't enough

A regex can tell you jane@gmial.com looks like an email. It can't tell you:

the domain has no MX records (mail is undeliverable),
it's a throwaway from a disposable-mail provider,
it's a role account (admin@, billing@) that never converts,
the user meant gmail.com.

Dead addresses pollute your list, tank your sender reputation, and waste onboarding emails.

One call, five checks

curl "https://email-validator109.p.rapidapi.com/validate?email=jane.doe@gmial.com" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: email-validator109.p.rapidapi.com"

const res = await fetch(
  "https://email-validator109.p.rapidapi.com/validate?email=" + encodeURIComponent(email),
  { headers: {
      "X-RapidAPI-Key": "YOUR_KEY",
      "X-RapidAPI-Host": "email-validator109.p.rapidapi.com",
  } }
);
const v = await res.json();

The response combines syntax validation, MX-record lookup, disposable-domain detection (checked against a ~121,000-domain list), role-account detection, and a did-you-mean typo suggestion — one JSON object.

What to do with the results

Invalid syntax / no MX → reject with a clear message.
Disposable domain → your call: block for trials, allow for downloads.
Typo suggestion → offer "Did you mean jane.doe@gmail.com?" — this alone recovers a surprising number of signups.
Role account → flag for sales/marketing lists rather than blocking.

Nothing is stored server-side; each request is validated in-memory.

Try it free

In-browser checker (no signup): abundanceapis.com/tools/email-validator. The API's free tier is 1,000 validations/month.

Fix CORS Errors in JavaScript: The 5-Minute Proxy Solution

Callie Schneider — Thu, 02 Jul 2026 07:20:30 +0000

Canonical version on our guides page. Disclosure: I built the proxy used in the examples — it has a permanent free tier.

Why the browser blocks your request

The same-origin policy restricts scripts to resources from the same scheme, host, and port. When your JavaScript fetches a different origin, the browser requires the response to carry an Access-Control-Allow-Origin header that permits your page. If the header is missing, the browser discards the response and logs the familiar error:

No 'Access-Control-Allow-Origin' header is present on the requested resource

For non-simple requests the browser also sends an OPTIONS preflight that the server must answer correctly.

The catch: you cannot change a third-party server's headers. A server-side proxy that adds the header is the standard fix.

The fix: route the request through a CORS proxy

curl "https://cors-proxy-web-toolbox.p.rapidapi.com/proxy?url=https://api.github.com/users/octocat" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: cors-proxy-web-toolbox.p.rapidapi.com"

const upstream = "https://api.github.com/users/octocat";
const res = await fetch(
  "https://cors-proxy-web-toolbox.p.rapidapi.com/proxy?url=" + encodeURIComponent(upstream),
  { headers: {
      "X-RapidAPI-Key": "YOUR_KEY",
      "X-RapidAPI-Host": "cors-proxy-web-toolbox.p.rapidapi.com",
  } }
);
const data = await res.json();
console.log(data.login); // "octocat"

The proxy fetches the upstream URL server-side, returns the body unchanged, and adds permissive CORS headers so the browser accepts it. GET and POST are supported, redirects are followed, and requests to private networks and internal IPs are blocked (SSRF protection — the proxy pins DNS-validated public IPs and re-validates every redirect hop).

When a proxy is the wrong tool

If you control the target server, set Access-Control-Allow-Origin there instead.
Never forward end-user credentials or session tokens through any third-party proxy. Keep proxied requests to public data.

Try it without signing up

There's a free in-browser tester at abundanceapis.com/tools/cors-proxy-tester — paste a URL and see the proxied response. The API itself has a free tier (1,000 requests/month).

Questions about CORS edge cases (preflights, credentials, redirects)? Happy to answer in the comments.