# Binding to 127.0.0.1 is not enough: keeping a local control API away from the web pages in your own browser

> Source: <https://dev.to/ashwar_sadh_f7abe6f82c8e9/binding-to-127001-is-not-enough-keeping-a-local-control-api-away-from-the-web-pages-in-your-own-276>
> Published: 2026-11-05 06:17:27+00:00

*Disclosure: I'm the developer of Relaymote, and this post is published from my account. It was drafted and published by an AI agent working on my behalf from the project's source code. Relaymote is unofficial; not affiliated with or endorsed by Anthropic.*

[Relaymote](https://github.com/ashwarsadh/relaymote) is an open-source (MIT) companion for Claude Code sessions on your PC. It runs a small daemon with a control API on `127.0.0.1`: the CLI, the MCP tools and a tray icon all talk to it, and it serves a local dashboard. Some of those endpoints start and stop work on your computer, so "who may call this" matters.

The usual answer is "it only listens on loopback, so only this machine can reach it". That is true, and it is not the whole threat model. This post is the 38-line guard that closes the rest.

Binding to `127.0.0.1` keeps *other machines* out. It does not keep out *a web page running in your own browser on this machine*. Two ways that goes wrong:

`POST http://127.0.0.1:<port>/api/task` with a form or `fetch(..., {mode: 'no-cors'})`. The page cannot read the response, but it does not need to: the request already did its work.`127.0.0.1` after the page loads. The browser now treats `http://evil.example:<port>` as same-origin with the page, and the page can send requests `Host` header, which says `evil.example:<port>`.
CORS does not help with either. CORS controls who may *read* a response; it does not stop a simple POST from arriving, and under rebinding the browser thinks there is no cross-origin request at all.

The fix starts with noticing that the real callers are easy to describe:

`Origin` header`localhost` or `[::1]`.
Everything else is someone else.

``` js
const LOOPBACK = ['127.0.0.1', 'localhost', '[::1]'];

function allowedHost(value, port) {
  const v = String(value || '').trim().toLowerCase();
  return LOOPBACK.some(h => v === `${h}:${port}`);
}

/** Returns null when the request may proceed, or { status, body } to refuse it. */
function check(req, port) {
  const h = req.headers || {};
  if (h.host !== undefined && !allowedHost(h.host, port)) {
    return { status: 403, body: { ok: false, error: 'BAD_HOST' } };
  }
  const safe = req.method === 'GET' || req.method === 'HEAD' || req.method === 'OPTIONS';
  if (safe) return null;
  if (String(h['sec-fetch-site'] || '').toLowerCase() === 'cross-site') {
    return { status: 403, body: { ok: false, error: 'CROSS_ORIGIN' } };
  }
  if (h.origin !== undefined) {
    let ok = false;
    try { const o = new URL(String(h.origin)); ok = o.protocol === 'http:' && allowedHost(o.host, port); } catch {}
    if (!ok) return { status: 403, body: { ok: false, error: 'CROSS_ORIGIN' } };
  }
  return null;
}
```

It runs first in the request handler, before any routing:

``` js
const refused = require('./lib/control-guard').check(req, PORT);
if (refused) return json(res, refused.status, refused.body);
```

Three rules, in order:

`GET` too: a rebinding page reading `/api/state` is a leak even if it changes nothing. The comparison is exact (`localhost:<port>`, not "contains localhost"), so `localhost.evil.example` does not pass.`HEAD` and `OPTIONS` change nothing, and the dashboard loads with them.`Sec-Fetch-Site: cross-site` is refused outright. If an `http:` on a loopback host and this port. A missing The test suite checks the cases that are easy to get wrong:

```
G('POST', { host: `127.0.0.1:${PORT}` })                                  // CLI / MCP: passes
G('POST', { host: `127.0.0.1:${PORT}`, origin: `http://127.0.0.1:${PORT}` }) // dashboard: passes
G('POST', { host: `127.0.0.1:${PORT}`, origin: 'https://evil.example' })  // CROSS_ORIGIN
G('POST', { host: `127.0.0.1:${PORT}`, origin: 'null' })                  // CROSS_ORIGIN
G('GET',  { host: `evil.example:${PORT}` })                               // BAD_HOST, even for GET
G('POST', { host: `localhost:${PORT}`, 'sec-fetch-site': 'cross-site' })  // CROSS_ORIGIN
```

`Origin: null` deserves a note. Sandboxed iframes, `file://` pages and some redirects send the literal string `null`. It is not "no origin"; it is a browser telling you it will not say. `new URL('null')` throws, `ok` stays false, and the request is refused.

The dashboard response is sent with `X-Frame-Options: DENY` (so another page cannot frame it and trick clicks onto its buttons) and `Cache-Control: no-store`. Neither replaces the guard; both are one header each.

It is not authentication. Any program already running as you on the same machine can call the API, exactly as it could read your files. The guard's job is narrower: a web page should not get the powers of a local program just because the browser happens to run on that machine. For a localhost API, that narrow job is the one most often skipped.

If you ship a local daemon with an HTTP control port (dev servers, desktop helpers, editor plugins), the checklist is short: exact loopback `Host` on every request, refuse `Sec-Fetch-Site: cross-site` on writes, and allow only your own loopback `Origin` or none.

Relaymote is on [GitHub](https://github.com/ashwarsadh/relaymote) under the MIT licence. Unofficial; not affiliated with or endorsed by Anthropic.
