Domain Whitelisting vs. Secret Tokens for API Request Security

Direct answer

Domain whitelisting alone is not sufficient protection against sophisticated request spoofing for public tokens. A secret token proxy adds a network hop; the latency cost becomes material only at high sustained request rates and depends on deployment topology, not a fixed volume threshold.

Confirmed facts

• Public access tokens are designed for client-side use and are visible in browser network traffic.
• Mapbox supports origin/domain restrictions on public tokens to limit use to registered hosts.
• Secret tokens are intended for server-side use, are not exposed to the browser, and can be scoped to specific APIs.
• If a public token is stolen it remains usable until revoked, regardless of domain restrictions.

Likely explanation and limits

Domain whitelisting relies on the Origin and Referer headers that Mapbox evaluates server-side. In normal browser use those headers are set by the user agent and are difficult to change for same-origin requests. The protection is limited because:

• Headers can be forged outside a browser, e.g., from custom scripts or compromised clients.
• A legitimate browser on a whitelisted domain can be used by an attacker to make requests with the exposed public token.
• Whitelisting does not hide the token; theft via dev tools, page source, or a supply-chain compromise remains possible.

For a secret token proxy, every map API call goes client → your server → Mapbox. The proxy eliminates token exposure and allows strict quota and scope control. Latency impact is deployment dependent. On a well-provisioned backend in the same region as the client, the added hop is typically low single-digit milliseconds per request. At tens of thousands of requests per second sustained, that hop can become a bottleneck unless the proxy is horizontally scaled and placed at the edge. No universal request-per-second threshold exists; the trade-off depends on your current peak RPS, p95 latency budget, and ability to scale the proxy.

Steps needed for this case

1. Classify which Mapbox endpoints must be called client-side for performance. Use public tokens with domain restrictions only for those endpoints.
2. Move all high-privilege or quota-sensitive calls behind a server proxy that injects a secret token with minimal scopes.
3. Enable token rotation and revocation monitoring for public tokens, and set short-lived usage alerts.
4. Measure current peak requests per second per edge and your latency budget before deciding on full proxy vs hybrid.

One missing diagnostic detail that changes the recommendation: your sustained peak requests per second per region and acceptable p95 latency increase for map tile / geocoding calls. With that figure a concrete proxy sizing and hybrid split can be determined.