Severity: Low · Calibrated

Unrestricted Google Maps API Key in a Synology asset

A client-side API key with no origin restrictions — and an honest read of how much it actually mattered.

About this page. This is a static case study. It makes no live API calls and the exposed key is redacted. An earlier version rated this issue Critical with invented dollar figures and ran live abuse calls; it has been recalibrated, because stating a finding's real impact accurately is the point.

The finding

Target	`note.synology.com`
Source	`notestation_gmap.js` (public client-side JavaScript)
Key	`AIzaSy…[REDACTED]` — masked; reported privately to the vendor
API surface	Google Maps / Places
Restrictions	None observed (usable from any origin)
Class	Exposed credential / missing key restriction (CWE-200, CWE-284)

Why it happens

Google Maps keys are designed to live in client-side code. The security control is not hiding the key — it's restricting it (by HTTP referrer, IP, or allowed API) so a visible key still only works from the owner's own sites. Here, those restrictions were missing.

Impact — stated plainly

An unrestricted, billable key can be reused from any origin to:

consume the owner's API quota / billing, and
power a third party's own map or geocoding features.

It does not bypass authentication, expose user data, or grant infrastructure access. Impact is bounded by whether the key is enabled/billed and by Google's per-key quotas and abuse protections. This is a hardening issue.

Recommended fix

Add HTTP-referrer (and/or IP) restrictions to the key.
Restrict it to only the specific APIs in use.
Rotate the key if unauthorized use is suspected.
Reference: Google — API key best practices.