Transparency
This site asks you to type in a Palworld server admin password. That creates an obligation to answer what happens to it. Every claim on this page is checkable against the source.
Data collected, where it is held, when it is destroyed
| Field | Held | Destroyed |
|---|---|---|
| Server address | Browser sessionStorage. If you check the remember option, localStorage instead. | On disconnect, or when the tab closes (sessionStorage) or the browser clears site data (localStorage). |
| Admin password | Browser sessionStorage or localStorage, same as above. The relay reads it from a request header, uses it to build one Basic auth header for the upstream call, and discards it. | On disconnect, or as above. Server-side: before the request handler returns. |
| Client IP address | Server memory, as a key in the rate-limit counters only. | When the rate-limit window expires: 4 minutes for authentication failures per client, 60 seconds for request counts per target host. |
| Target hostname | Server memory, as a key in the target-host rate-limit counters only. | When the 60 second target-host rate-limit window expires. |
| Server metrics, player roster, map positions | Displayed in the browser tab. Not written to any storage, server or client. | When you navigate away or disconnect. |
Server-side retention
The relay persists nothing to disk. It holds nothing in a database. The admin password, target host, port, and every response body live for the duration of one request and are gone when the handler returns.
The one exception: rate-limit counters. Two buckets run in server memory.
- Per client IP, counting failed authentication attempts. 4 failures in 4 minutes returns 429 for the remainder of the window.
- Per target host, counting total requests across all clients. 600 requests in 60 seconds against one host returns 429 for the remainder of the window.
Both counters are keyed by client IP and target host. Both live only in memory. Both are destroyed when their window expires. Neither survives a deploy or a restart.
What is logged
Stated at field level, so nothing is hidden in a general claim.
| Field | Logged | Note |
|---|---|---|
| Admin password | No | Striped from every log line and every error response. The Authorization header is never written to a log. |
| Request method and path | Yes | Standard HTTP request log. GET /api/relay/info, POST /api/relay/kick, and so on. |
| Target hostname | May appear in request logs | The relay reads the target from a request header. The hostname may reach the server runtime log as part of the request. It is not extracted into a separate log field and is not retained beyond the request lifetime except as a rate-limit counter key. |
| Client IP | May appear in request logs | Standard in HTTP server logs. The relay does not extract or store it separately from the rate-limit counters described above. |
| Request body (kick reason, announce message, etc.) | No | Forwarded to the upstream server, not retained or logged by the relay. |
| Error details and stack traces | Server-side only | Error responses to the client carry a generic message. Stack traces and internal detail stay on the server. |
Residual risk
This site is an authenticated open proxy to public high ports. No amount of hardening changes that classification. The controls reduce it to this: an attacker can send well-formed Palworld REST requests to a public host on a high port, at a bounded rate, and observe whether the response was a 401 or a connection error. That is the residual risk, and it is accepted.
The controls that narrow the risk to that description are a path allowlist permitting twelve endpoints only, private and reserved address denial covering every RFC1918 and special-use range plus both cloud metadata addresses, resolved address pinning that prevents DNS rebinding, no redirect following, a port floor at 1024, a 10 second timeout, a 2 MB response cap, and two rate-limit keys. Removing any one of them restores the full vector.
Transport
The browser-to-site leg is HTTPS, terminated at the edge. The site-to-game-server leg is plain HTTP with Basic authentication. Your admin password crosses the public internet base64-encoded and otherwise in the clear on that second leg. This is a property of the Palworld REST API, which serves only HTTP, and it cannot be fixed on our side. It can only be disclosed.
If you have put a reverse proxy with TLS in front of your game server, the relay uses HTTPS for that connection and the plaintext exposure does not apply.
Source
Every claim on this page is checkable against the implementation. github.com/indifferent-ketchup/palworldadmin