Weak same-origin guard in dev-server /api/* endpoints can be bypassed with forged Referer substring

[rspiegel-nc]

The dev server now blocks unauthenticated /api/* access unless isSameOrigin(req) passes, but the current implementation is too weak:

function isSameOrigin(req) {
  const origin = req.headers.origin || req.headers.referer || '';
  return origin.includes(`localhost:${PORT}`) || origin.includes(`127.0.0.1:${PORT}`);
}

This trusts any Origin or Referer string that merely contains localhost:PORT or 127.0.0.1:PORT as a substring. It does not parse and compare the actual origin.

As a result, a foreign header such as:

Referer: https://evil.example/?next=http://127.0.0.1:8000/

is incorrectly accepted as same-origin.

Why this matters

This is not a strict same-origin check. It is a substring check on attacker-controlled header content.

That means /api/* endpoints are still reachable if the request carries a misleading Referer or Origin value containing the local dev URL somewhere inside the string.

Even if ordinary browser fetch() from unrelated sites may now be blocked in many cases, the server-side trust decision is still wrong and should be fixed. The current implementation is fragile and can be bypassed by forged headers or non-browser clients.

Confirmed reproduction

Server running at:

http://127.0.0.1:8000/

1. No headers: correctly blocked

curl -i "http://127.0.0.1:8000/api/check-url?url=https://example.com"

Response:

HTTP/1.1 403 Forbidden
...
Forbidden

2. Forged foreign Referer containing local URL substring: incorrectly allowed

curl -i "http://127.0.0.1:8000/api/check-url?url=https://example.com" \
  -H "Referer: https://evil.example/?next=http://127.0.0.1:8000/"

Response:

HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: *
...

{"status":0,"error":"unable to get local issuer certificate"}

The upstream TLS error is unrelated. The important part is that the request was accepted and forwarded instead of returning 403.

3. Same bypass works on /api/proxy

curl -i -X POST "http://127.0.0.1:8000/api/proxy" \
  -H "Content-Type: application/json" \
  -H "Referer: https://evil.example/?next=http://127.0.0.1:8000/" \
  --data '{"url":"https://example.com","method":"GET","headers":{}}'

Response:

HTTP/1.1 502 Bad Gateway
Content-Type: application/json
Access-Control-Allow-Origin: *
...

{"error":"Upstream error: unable to get local issuer certificate"}

Again, the upstream certificate failure is not the issue. The issue is that the request bypassed the same-origin guard and reached the proxy logic.

Expected behavior

The server should only accept requests whose actual origin matches the local dev origin exactly.

Examples that should be accepted:

• http://127.0.0.1:8000
• http://localhost:8000

Examples that should be rejected:

• https://evil.example/?next=http://127.0.0.1:8000/
• https://127.0.0.1:8000.evil.example
• any unrelated origin containing the local URL as a substring

Suggested fix

Parse and compare exact origins instead of using substring matching.

For example:

function isSameOrigin(req) {
  const allowed = new Set([
    `http://127.0.0.1:${PORT}`,
    `http://localhost:${PORT}`,
  ]);

  if (req.headers.origin) {
    return allowed.has(req.headers.origin);
  }

  if (req.headers.referer) {
    try {
      return allowed.has(new URL(req.headers.referer).origin);
    } catch {
      return false;
    }
  }

  return false;
}

It would also be reasonable to rely only on Origin for API endpoints and avoid Referer fallback entirely unless there is a strong compatibility reason.

[robert7]

sorry wrong GH username, it is still me :)

[elkimek]

Will look into it tmrw, thanks :)

[elkimek]

Thanks for the detailed write-up and the suggested fix — you were right, the substring check was the wrong tool for the job. Took your proposed implementation almost verbatim in #120: exact-match Set lookup on new URL(referer).origin after the parse, with the same try/catch around malformed Referer.

Kept the Referer fallback (some browsers omit Origin on same-origin GET fetches, which would break /api/check-url and /api/fetch-page) — but the parsing makes that fallback safe now since forged substrings can't sneak through. Also added http://[::1]:PORT to the allowlist while in there.

Added a Node-side regression test (tests/test-dev-server-origin.js, 12 assertions) covering the original repro plus IPv6, lookalike origins (http://localhost:8000.evil.example), and malformed Referers. Will be in v1.19.3.

[robert7]

Hi,
just rechecked with commit id 3808c5f.
Is getting better, but still not fully safe...

node dev-server.js
Dev server running at http://127.0.0.1:8000
  /        → index.html (no site repo found at /Users/robert/Projects/_private/get-based-site)
  /docs/*  → dist-docs/*

curl -i "http://127.0.0.1:8000/proxy?url=http://example.com" \
             -H "Origin: https://evil.example"

HTTP/1.1 200 OK
Content-Type: text/html
Access-Control-Allow-Origin: *
Date: Wed, 15 Apr 2026 11:38:58 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Transfer-Encoding: chunked

<!doctype html><html lang="en"><head><title>Example Domain</title><meta name="viewport" content="width=device-width, initial-scale=1"><style>body{background:#eee;width:60vw;margin:15vh auto;font-family:system-ui,sans-serif}h1{font-size:1.5em}div{opacity:0.8}a:link,a:visited{color:#348}</style></head><body><div><h1>Example Domain</h1><p>This domain is for use in documentation examples without needing permission. Avoid use in operations.</p><p><a href="https://iana.org/domains/example">Learn more</a></p></div></body></html>

[robert7]

I can't reopen the issue...

[robert7]

[robert7]

This is a separate remaining issue from the /api/* same-origin fix.

The new exact-origin validation appears to fix /api/*, but the legacy GET /proxy?url=... route is still reachable cross-origin and still behaves as an open read-capable proxy.

So the original risk is not fully eliminated; it still exists via /proxy.
Please either remove /proxy entirely, or apply the same exact-origin guard to it as well.