API Key Security

Best practices for protecting your API keys, understanding origin restrictions, and safely deploying to production.

Why Origin Restrictions Matter

LandMap API keys are designed to be used in the browser — your mapping application includes the key in tile and query requests directly from the client. This means anyone who views your page source, inspects network traffic, or opens browser dev tools can see your API key.

Without origin restrictions, a stolen key can be used from any website or script, consuming your token balance. Origin restrictions ensure your key only works when requests come from your domain(s).

Origin restrictions are enforced at the API gateway level. Requests from unauthorized origins are rejected before any tokens are consumed.

localhost Is Not Safe

A common misconception is that restricting a key to localhost or 127.0.0.1 provides protection. It does not.

The HTTP Origin header is set by the browser, but any server-side script can send requests with a forged origin header. A localhost-only key is effectively unrestricted.

Use localhost keys only during development. Before deploying, update the key with your production domain or create a separate production key with proper restrictions.

Setting Origin Restrictions

In the API Keys section of your dashboard, set the Allowed HTTP Origins field to your production domain(s). You can use exact domains or wildcards:

Origins

https://myapp.com
*.myapp.com
https://staging.myapp.com

Wildcard patterns like *.myapp.com match any subdomain (e.g. app.myapp.com, maps.myapp.com).

Server-side vs Browser-side Keys

Not all API keys are used in the browser. If you are calling the LandMap API from your own backend server, the key never appears in client-side code and origin restrictions are not necessary.

Use Case	Origin Restrictions
MapLibre / Google Maps in browser	Required — add your domain(s)
Your backend server calling the API	Not needed — key stays server-side
Local development / testing	Not needed — switch to restricted key for production
Desktop apps (QGIS, ArcGIS)	Use user agent restrictions instead

Best Practices

Use separate keys for development and production. Keep your dev key unrestricted, lock down your production key.
Restrict production keys by domain before deploying to a public website. This is your primary defense against key theft.
Monitor usage in the dashboard. Unexpected spikes may indicate unauthorized use.
Rotate keys if you suspect one has been compromised. Create a new key, update your app, then revoke the old one.
Never commit keys to version control. Use environment variables or a secrets manager.