I built an API client that runs in your browser. Here's how I handled CORS without running an open proxy

I created a browser-based API client for Tool Reign that does not require an open proxy. However, the project does come with some design considerations, particularly around the proxy functionality. Browsers can send requests to any URL, but they only allow the page to read the response if the server permits it. This is known as CORS (Cross-Origin Resource Sharing), and many APIs do not allow it.

Other limitations include certain headers that cannot be set from a page, the inability to read Set-Cookie headers, and the limitation of only seeing the response headers the server chooses to expose.

There are two modes available: direct and proxy. Direct mode sends the request from the browser to the API directly, without any intermediaries. It works for any API that allows CORS and is the default mode. The proxy mode, which is opt-in, sends the request through Tool Reign's server, then to the API. This mode reveals headers, cookies, and timing that the browser typically hides, and it works for APIs that block browser requests.

The proxy is designed to mitigate the risk of server-side request forgery and abuse. It resolves hostnames itself and rejects any private or reserved addresses, such as loopback, private ranges, link-local, carrier-grade NAT, multicast, and IPv6 equivalents. It also prevents automatic redirects and sets limits on request size, response size, and time.

The tool only accepts calls from its own origin and implements rate limits per client. No personal data is stored, with the app's logs only containing a request ID, status class, error code, and duration.

Privacy is a significant concern. Users often input sensitive information like tokens and keys into an API client, and a proxy can see this data. Therefore, the proxy option is opt-in, and there is a consent notice presented the first time the user uses it. The advice is to avoid using production credentials through the proxy. The app logs minimal data, with no URLs, headers, or bodies stored.

The development process encountered a few issues. First, the zip file created on Windows with PowerShell's Compress-Archive contained paths with backslashes, which caused problems on the Linux host. Switching to a tar-built zip resolved the issue. The health check posed another problem because the platform probing the app to check if it was alive was being rejected due to an origin check.

Health routes need to be exempt from this check. Lastly, a DNS issue arose where the root domain's A record turned into a parked placeholder, leading visitors to the registrar's parked page. After checking DNS after every domain change, the issue was resolved.

The tool includes a variety of features such as collections, environments with variables, request history, parameters, headers, body, and authentication, plus response body, headers, cookies, and timing. It also provides code snippets and options for import, backup, and restore. You can try the tool at https://toolreign.com/developer/api-client/. I welcome feedback on what's missing and am open to answering architecture questions in the comments.