Desktop App Local API IDOR: Hunting Bindings on Localhost

Desktop App Local API IDOR: Hunting Bindings on Localhost

Many desktop clients run a companion HTTP server on 127.0.0.1 for the UI, extensions, or media features. That socket feels private. Browsers and other local processes can often still talk to it. When object authorization is weak, you get IDOR with a LAN-free exploit path.

Find the listener

During install or login, watch listening ports (netstat, ss, or Process Monitor). Note the port, bind address, and process. 127.0.0.1 is safer than 0.0.0.0, but neither replaces authz. Some apps rotate ports; check lock files, config JSON, or custom URI schemes that embed the port.

Hit /, /api, /graphql, /status, and any paths the Electron or native UI calls. Burp's upstream proxy or a simple curl from another local process is enough. Compare traffic from the official UI with what an unauthenticated local client can do—parity without a session cookie is a red flag.

Abuse cases that matter

Cross-site calls from a malicious webpage toward http://127.0.0.1:PORT depend on browser mixed-content and CORS behavior. Some apps set Access-Control-Allow-Origin: * on the local API. Others skip CORS entirely for "local only" and still answer simple requests from the browser in older setups—or from another desktop app.

Even without a browser entry point, any local malware or another user process on a shared machine can call the API. Programs differ on whether same-machine attack assumptions are in scope—read the policy. When in scope, missing auth on a local API that can read chat databases or tokens is a solid finding.

IDOR shows up when the local API proxies to cloud backends with the user's session but accepts arbitrary resource ids:

• GET /local/files/{id}
• POST /import?path=
• GET /vault/entries/{uuid}

Swap ids across two logged-in profiles if the app supports multiple accounts, or between your account and a canary object. Path traversal in path query params is a cousin of IDOR here—try reading a canary file you created outside the intended directory.

Bind address and authentication

If the service listens on all interfaces, LAN peers may connect. Pair that with no auth and you have a network-adjacent data leak. Prefer proofs on your own Wi-Fi lab, not a coffee shop full of strangers.

Look for static tokens in the UI bundle, default keys, or cookies set without HttpOnly expectations on localhost quirks. Websocket local endpoints need the same id checks as HTTP. Origin headers on local requests are easy to spoof from non-browser clients—do not treat them as authentication.

Write a tight report

Include bind address, port discovery method, exact request, and the private canary returned. Recommend loopback-only binds, per-session random ports with origin checks, CSRF protections for browser-reachable verbs, and server-side ownership filters on every proxied object id.

Local APIs are small attack surfaces with outsized access. Enumerate the socket, treat it like production, and prove one unauthorized read before you claim the desktop client is "just a UI."

If the local server mirrors cloud pagination, try limit and offset extremes on list endpoints—bulk export without ownership filters is still IDOR, just louder.