Which API Keys Are Exposed to the Browser in God's Eye View and How Are They Restricted?
Only the Google Maps API key and Cesium Ion token are shipped to the browser bundle, and both require strict provider-side restrictions—HTTP referrer limits for Google and URL restrictions for Cesium—to prevent unauthorized usage and billing abuse.
God's Eye View is an open-source geospatial visualization stack that deliberately minimizes client-side credential exposure. While most API secrets remain server-side, two keys must reach the browser to enable direct 3D tile fetching from external providers.
Client-Side Credentials in God's Eye View
The application exposes exactly two credentials to the client bundle. All other secrets—including OpenAI, AISStream, and OpenSky OAuth credentials—are strictly server-side.
Google Maps API Key
The GOOGLE_MAPS_API_KEY enables rendering of Google's 3D Tiles. According to the source code in vite.config.js (lines 22-23), this key is explicitly marked for client exposure via import.meta.env.VITE_GOOGLE_MAPS_API_KEY. The browser uses this credential to fetch tiles directly from tile.googleapis.com without proxying through the backend.
Cesium Ion Token
The CESIUM_ION_TOKEN provides access to Cesium-hosted imagery and terrain assets. As implemented in src/mapStackController.js, this token is assigned to Cesium.Ion.defaultAccessToken at runtime. The Vite build process injects it as import.meta.env.VITE_CESIUM_ION_TOKEN, making it visible in the client bundle.
How Keys Are Injected into the Browser Bundle
The build pipeline uses Vite's define configuration to inline environment variables into the client code. This process occurs in vite.config.js:
// vite.config.js (excerpt)
export default defineConfig({
define: {
'import.meta.env.VITE_GOOGLE_MAPS_API_KEY': JSON.stringify(process.env.GOOGLE_MAPS_API_KEY),
'import.meta.env.VITE_CESIUM_ION_TOKEN': JSON.stringify(process.env.CESIUM_ION_TOKEN),
},
// ...additional configuration
});
During compilation, these values become hardcoded strings in the JavaScript bundle. A user inspecting network traffic or bundle files will see the raw key values, which is why provider-side restrictions are mandatory.
Runtime Usage and Implementation
The exposed keys are consumed immediately upon map initialization. In src/mapStackController.js, the Cesium token is set globally before any assets load:
// src/mapStackController.js (excerpt)
Cesium.Ion.defaultAccessToken = import.meta.env.VITE_CESIUM_ION_TOKEN;
// Google Maps Tiles loader construction
const googleKey = import.meta.env.VITE_GOOGLE_MAPS_API_KEY;
const tilesUrl = `https://tile.googleapis.com/v1/tiles/{z}/{x}/{y}?key=${googleKey}`;
This direct browser-to-provider communication architecture eliminates server latency for tile streaming but necessitates that the credentials travel with the client code.
Server-Side Protection for Sensitive Credentials
All other API credentials are isolated from the browser through a proxy architecture. The src/keySetupCore.mjs module handles the POWER UP panel logic, writing secrets exclusively to server-side .env files and never echoing them back to the client.
The development server proxies requests requiring private credentials (such as OpenAI completions or AISStream data), ensuring secrets remain in Node.js memory. Additionally, the server enforces per-IP rate limiting via GEV_RATELIMIT_GOOGLE_PER_MIN and GEV_RATELIMIT_OPENAI_PER_MIN environment variables to mitigate abuse if any credential is accidentally exposed.
Required Provider-Side Restrictions
Because both keys are visible in the client bundle, you must restrict them at the provider level according to the security model documented in SECURITY.md (lines 24-30).
Restricting the Google Maps API Key
In the Google Cloud Console, apply these constraints:
- API restrictions: Limit the key to only the Maps Tiles API.
- HTTP referrer restrictions: Add your hosted domain and
localhostdevelopment URLs. This prevents third-party websites from embedding your key and consuming your quota.
Restricting the Cesium Ion Token
In your Cesium Ion account settings:
- Token type: Use a public "assets:read" token from a Cesium Ion Community plan.
- URL restrictions: Whitelist only your production domain and local development origins. This binds the token to your specific deployment, rendering it useless if extracted and reused elsewhere.
Summary
- Only two keys ship to the browser:
GOOGLE_MAPS_API_KEYandCESIUM_ION_TOKEN, both injected via Vite'sdefineblock invite.config.js. - All other secrets remain server-side: OpenAI, AISStream, and OpenSky credentials are accessed only through backend proxies implemented in
src/keySetupCore.mjs. - Provider restrictions are mandatory: Google keys require HTTP referrer and API restrictions; Cesium tokens require URL restrictions to prevent unauthorized usage.
- Rate limiting provides secondary protection: Per-IP limits (
GEV_RATELIMIT_GOOGLE_PER_MIN,GEV_RATELIMIT_OPENAI_PER_MIN) help contain any accidental exposure.
Frequently Asked Questions
Are OpenAI API keys exposed to the browser in God's Eye View?
No. OpenAI keys remain strictly server-side. The application proxies all OpenAI requests through the backend, where the key is stored in environment variables and never transmitted to the client. This architecture prevents token theft and allows the server to enforce rate limits via GEV_RATELIMIT_OPENAI_PER_MIN.
How do I restrict the Google Maps API key for local development?
In the Google Cloud Console, add http://localhost:5173 (or your specific dev port) to the HTTP referrer whitelist. Also restrict the key to the Maps Tiles API only. This allows local testing while blocking external domains from using your key if they obtain it from the browser bundle.
What happens if I don't restrict the Cesium Ion token?
An unrestricted token can be used by anyone who extracts it from your JavaScript bundle to access Cesium assets under your account. This could exhaust your monthly tile requests or incur overage charges. URL restrictions ensure the token only functions when the request originates from your approved domains.
Where does God's Eye View store sensitive API keys?
Sensitive keys (excluding the two client-side tokens) are written to a server-side .env file by the src/keySetupCore.mjs module. The POWER UP panel in the UI sends keys to this backend handler, which validates them and persists them to environment variables without exposing them in API responses or client code.
Have a question about this repo?
These articles cover the highlights, but your codebase questions are specific. Give your agent direct access to the source. Share this with your agent to get started:
curl -s "https://instagit.com/install.md" Maintain an open-source project? Get it listed too →