Redact sandbox tokens from ingress access logs
Set up your network gateway to redact short-lived authentication tokens from access logs.
Self-hosted deployments use a sandboxed null-origin iframe (sandbox="allow-scripts") to isolate developer-authored code from the editor host when building apps with Retool's new app builder. Because null-origin iframes cannot carry cookies, the iframe authenticates sub-resource requests by including a short-lived JSON Web Token (JWT) in the URL as ?sandboxToken=<jwt>.
Your ingress controller's access logs capture the full request URL by default, which means these tokens appear in your log retention. The tokens are scoped to a single sandbox and user with a one-hour expiry, but Retool recommends scrubbing them at the ingress layer as defense-in-depth — particularly if you ship access logs to a third-party Security Information and Event Management (SIEM) or log analytics platform.
This guidance applies to any network gateway between your users and Retool that logs the full request URL — Kubernetes ingress controllers, cloud load balancers, CDNs, web application firewalls (WAFs), and service mesh gateways.
What's in the logs today
The following example displays a token-bearing request line from a typical ingress NGINX access log:
"GET /sandbox/sandbox-12f566f1-9270-…/agent-vite/?sandboxToken=eyJhbGciOiJFUzI1NiIs… HTTP/2.0" 200
The ?sandboxToken=eyJ… segment is the JWT. You may also see related parameters in limited circumstances:
| Parameter | Where it appears | Sensitivity |
|---|---|---|
?sandboxToken= | Editor preview entry HTML and WebSocket upgrade URLs | High — short-lived session JWT (~1 hour) with full sandbox API access |
/_t/<token>/ path segments | Asset sub-resource fetches from null-origin iframes | Medium — HMAC-signed static-asset reader (GET-only; cannot reach /retool-api/* or mutate state) |
?retool-theme=, ?retool-parent-origin=, ?retool-iframe-hosted-mode= | Editor preview iframe configuration | Not sensitive |
Retool's own service-layer container logs (the application stdout and stderr that Container logs describes) are scrubbed of these tokens at the application layer, but your ingress controller's access logs are written upstream and aren't covered by that scrubbing.
Mitigation
Configure your ingress controller — or your downstream log analytics pipeline — to match the following patterns in the access-log output and replace each match with [REDACTED] before the log is stored or forwarded:
- Query-string tokens:
(?:sandboxToken|accessToken|xsrfToken)=[^&\s]+ - Path-segment asset tokens:
/_t/[^/?#]+/
Each ingress controller and log aggregator exposes log-field rewriting differently. Refer to your controller's documentation for the exact mechanism.
Defense in depth
Two facts limit the practical impact of a token leak:
- Scope. Each
sandboxTokenis bound to a single sandbox, a single user, and a single organization. Compromise of one token grants one hour of access to that one developer's edit-mode sandbox — not to other tenants, not to other users, not to published apps consumed by end users. - Lifetime. Tokens expire after one hour with no refresh path. An exfiltrated token that is not used within that window is inert.
Ingress access logs are commonly retained for 30 or more days and forwarded to multiple downstream systems. Redacting at the log layer costs nothing operationally and removes the tokens from a sink where they have no defensive purpose.
See also
- Container logs — what Retool's own service-layer logs contain (already scrubbed at the application layer) versus what your ingress-controller access logs contain.
- Logging environment variables — reference for application-layer log configuration.