A browser-based map can use a credential without making that credential truly secret. This guide explains how to secure mapping API keys with provider restrictions, environment variables, server-side proxies, request signing, monitoring, and a repeatable review process for every deployment or suspected leak.
Overview
When a map renders in a browser, the browser must receive enough information to request map tiles, styles, geocoding results, or other API resources. That means developers should assume that a credential included in frontend JavaScript, an HTML page, a network request, or a source map can be discovered by a user. An environment variable can keep a value out of source control, but it does not make a value private once a frontend build inserts it into the shipped application.
The right security model depends on what the credential can do. A public browser key may be acceptable for map display when it is narrowly restricted by website, application, API, and quota controls. A credential that grants access to sensitive data, unrestricted server-side APIs, billing-sensitive operations, or privileged account actions should remain on a server. In that design, the browser calls your backend and the backend calls the mapping provider.
There is no single protection that solves every exposure. Referrer or domain restrictions limit where a browser key can be used. API and product restrictions limit which services it can call. Quotas and alerts help contain abuse. A proxy keeps a server credential away from the browser. Logging and rotation provide recovery when a key is exposed. Treat these controls as layers rather than substitutes for one another.
For broader integration context, compare the tradeoffs among providers in Google Maps, Mapbox, and Leaflet before selecting a credential architecture.
What to track
Credential location and exposure
Maintain an inventory of every mapping credential and record where it is used: local development, preview deployments, production websites, server workloads, CI jobs, and third-party monitoring tools. For each entry, note whether the value is visible to browsers, stored in a repository, embedded in a bundle, or injected only at runtime on a server.
Search source control and build artifacts for old key names, token prefixes, configuration files, generated JavaScript, source maps, and copied documentation. Review browser developer tools on a deployed map to see which credentials and endpoints are visible in requests. The purpose is not to hide a browser key; it is to confirm that no server-only credential has crossed the frontend boundary.
Restrictions and allowed services
Track the restrictions applied to each browser credential. Depending on the provider, useful controls may include allowed domains or referrers, application identifiers, permitted APIs, package or bundle restrictions, and separate credentials for development, staging, and production. Use the narrowest set of origins and services that supports the application.
Do not treat a domain restriction as permission to expose every mapping capability. A key used only to display a map should not automatically be able to call unrelated search, routing, administration, or data-management endpoints. Review whether the provider supports separate keys for separate products, environments, or workloads.
Usage, quota, and error signals
Record normal request patterns for map loading, geocoding, reverse geocoding, routing, autocomplete, and other enabled features. Watch for sudden increases, requests from unfamiliar origins, unexpected endpoint usage, authentication failures, and browser errors after a domain migration. Quota controls can reduce the impact of accidental loops or unauthorized use, but they should be configured with the expected workload in mind.
Keep logs useful without collecting sensitive location searches or complete user inputs unnecessarily. Log a request category, environment, status, latency, and a non-secret credential identifier or version. Never log the full API key, authorization header, signed URL, or private proxy secret.
Build and deployment handling
Environment variables are valuable for separating configuration from source code, but frontend frameworks commonly expose selected variables during the build. Use the framework's documented public-variable convention only for values that are safe to deliver to the browser. Keep server-only variables in server runtime configuration, secret stores, or deployment settings, and verify that they are not copied into client bundles.
Check pull requests for accidental key additions, restrict who can view production secrets, and make generated build output part of the security review. A secure local .env file does not protect a credential if the build process publishes it in JavaScript.
Cadence and checkpoints
A practical review cadence is monthly or quarterly, with additional checks whenever the application or provider configuration changes. The exact interval should reflect request volume, sensitivity, team size, and the consequences of unauthorized use.
| Checkpoint | Review | Action |
|---|---|---|
| Monthly | Usage, errors, quotas, active domains, and unusual origins | Investigate anomalies and remove obsolete origins or APIs |
| Quarterly | Credential inventory, repository history, bundles, source maps, and access permissions | Retire unused keys and confirm server-only values remain private |
| Every deployment | Environment variables, build output, domain settings, and staging-to-production differences | Test the deployed map and verify restrictions match the real origin |
| After a suspected leak | Repositories, logs, browser captures, tickets, and chat messages | Revoke or rotate the exposed credential, assess use, and restore least-privilege settings |
Include the map in normal release testing rather than checking only whether tiles appear. Test geocoding, marker loading, reverse geocoding, routing, and failure states separately. A working map can conceal an over-permissioned key, while a failed map can result from an incorrect production domain rather than a compromised credential. The frontend API debugging checklist can help separate CORS, fetch, headers, and network configuration problems.
How to interpret changes
An increase in usage is not automatically an attack. It may follow a product launch, a new map view, a crawler discovering a page, a retry loop, or a change in geocoding behavior. Start by comparing the change with deployments, traffic, request types, origins, and response codes. A usage increase that matches legitimate traffic is different from a new request pattern from an unrecognized origin.
Frequent authorization errors usually point to a configuration mismatch: an unapproved domain, an incorrect API being used, a missing environment variable, or a credential that was rotated without updating the deployment. A large number of successful requests from an unexpected origin is more concerning because it suggests that a browser-visible key is being reused. Restrict the credential further, inspect application and provider logs, and rotate it if exposure is plausible.
Use a server-side proxy when the operation requires a private credential or when the application needs stronger control over inputs, authorization, caching, and rate limiting. The browser should call an endpoint owned by your application; the server validates the request, applies limits, calls the mapping provider, and returns only the required result. A proxy does not remove the need for authentication, input validation, abuse controls, and monitoring.
Signed requests can help authenticate or validate certain server-to-provider requests when a provider supports them, but signing should happen on a trusted server. Do not place a signing secret in frontend code. Provider-specific signing formats, restrictions, and rotation procedures vary, so confirm the current implementation requirements before adopting this pattern.
If a key is exposed, preserve relevant evidence, disable or rotate the credential according to the provider's controls, check usage during the exposure window, remove it from source and deployment configuration, and issue a replacement with narrower permissions. Rewriting the latest commit is not enough if the value exists in repository history, build artifacts, logs, or copied configuration.
When to revisit
Revisit this article and your credential checklist whenever you add a mapping feature, change domains, move from a static frontend to a server-rendered application, introduce a proxy, change build tooling, or switch providers. A staging hostname, preview URL, CDN, or new subdomain can invalidate an otherwise correct domain restriction. A new geocoding or routing feature can also require a separate API permission or a different server-side control.
Use a short deployment checklist:
- Classify each credential as browser-visible or server-only.
- Confirm browser credentials have the narrowest domain, API, and quota restrictions available.
- Verify public environment variables contain no private signing or server credentials.
- Inspect the production bundle and browser network requests for accidental exposure.
- Test expected map features and deliberate failure cases from the real production domain.
- Review usage and error signals after release, then record the credential owner and rotation date.
For implementation testing, use mock map data where possible and reserve live requests for focused integration checks. This reduces accidental usage during development and makes failures easier to reproduce. When the application includes address search or reverse geocoding, pair this security review with the JavaScript geocoding integration guide. The goal is a repeatable workflow: expose only what the browser needs, keep privileged credentials server-side, monitor the signals that matter, and update the controls whenever the application changes.
