PeeringDB just landed a commit that fixes one of the most common and easily avoidable API key leaks in web applications: using a single Google Maps key for both server-side geocoding and client-side map rendering.
The Problem: One Key to Rule Them All (Badly)
Your browser-side JavaScript is public. Every line of it. When you embed a Google Maps API key in a <script> tag, that key is visible to anyone who opens DevTools. If that same key also powers server-side geocoding (which cannot use HTTP-referrer restrictions because the server isn't a browser), an attacker can steal the key and hit Google's billing endpoint at your expense.
PeeringDB had exactly that setup. The single GOOGLE_GEOLOC_API_KEY was used both for server-side geocoding and as the key rendered into the advanced-search page. A tidy time bomb.
What the Commit Actually Does
Commit ce43461 introduces a new environment variable: GOOGLE_MAPS_API_KEY. This key is for the browser-side Google Maps JavaScript API. It should carry HTTP-referrer restrictions so only requests from peeringdb.com (or wherever the app runs) are accepted. The existing GOOGLE_GEOLOC_API_KEY stays server-side only, used for geocoding lookups with no referrer check.
The fallback logic is clean: if GOOGLE_MAPS_API_KEY is unset, the code falls back to GOOGLE_GEOLOC_API_KEY, preserving backward compatibility. The test in tests/test_views.py verifies both paths: without the new variable, the page renders AIzatest; with GOOGLE_MAPS_API_KEY set to AIzamapstest, the browser key switches.
A small but critical detail: the comment in mainsite/settings/__init__.py explains the reasoning explicitly. That comment is worth reading - it documents the threat model for the next person touching this config.
Why This Pattern Matters Beyond PeeringDB
This isn't just a peeringdb fix. It's a textbook example of separating concerns at the API key level. Every project that embeds Google Maps (or any third-party JS SDK) should enforce a strict split between keys meant for public, referrer-restricted use and keys used in server-to-server calls.
PeeringDB's approach - a dedicated env var, a clear fallback, and tests that assert the key in the rendered HTML - sets a standard that any Django app can replicate. The commit is small (6 lines of settings, 5 lines of views, 24 lines of test), but the security impact is large.
With this pattern now documented in peeringdb's test suite, other Django projects have a clear template for the same fix.
Source: Split google maps api key (#1994)
Domain: github.com
Comments load interactively on the live page.