Umami separates browser login, API keys and public share tokens
Umami exposes analytics through a web application, an API and optional public share pages. The official authentication documentation distinguishes two self-hosted API methods: API keys, which are recommended, and username-password exchange for a token. It also describes API keys as long-lived credentials that do not expire and can be revoked individually. That combination makes lifecycle review important.
On 2026-11-05, a count-only ZoomEye query with sub_type=all, page 1 and page size 1 returned 11,535 matches for app="Umami". The title query returned 18,762. Those results describe matching application surfaces and must be separated from the question of whether a share page or API key is exposed.
Umami's API reference also uses share tokens. Some endpoints require a signed share token and a share-context header in addition to authorization, depending on the operation. A share URL is designed to expose selected dashboard views publicly. The important question is which traffic, behavior and growth views the owner enabled. A dashboard that looks limited in the UI can still return more data through a copied share token.
Treat the three credential paths differently
API keys are for scripts and integrations. Create one for each consumer where possible, name it after the service, record its owner and delete it when the integration ends. Because the key does not expire, put a calendar review and a revocation procedure in place. Do not put it in browser JavaScript or a public repository. If it is exposed, delete the key and inspect the API activity that occurred while it was valid.
Login tokens and passwords belong to human sessions. Encourage MFA where the deployment offers it and remove departed users promptly. A password change should invalidate the sessions that the application intends to invalidate; test that behavior rather than assuming it.
Public share links are deliberate bearer capabilities. Set the narrowest view set available, review whether the share should be disabled after a project ends, and remember that URL filters can disclose more than the landing view suggests. Keep an inventory of share links and their owners. Do not reuse an administrative login token in a share integration.
Place access controls around the whole service
Put the Umami dashboard and its administrative API behind the approved network or SSO boundary. The tracking endpoint may need to be public, but the reporting API and management routes do not. Check reverse-proxy hostnames and direct listeners. Restrict database access to the application and backup jobs, and encrypt backups that contain visitor data.
Watch for authorization changes that affect several teams or websites. A token created under one team context may not represent the same access as a global administrator's browser session. Validate the scope with a request that should return only the intended site and a request that should fail. Keep the source IP, timestamp and key identifier in the audit record.
The ZoomEye measurement is a starting point for owned-instance verification. It does not prove an unauthenticated dashboard or an exposed share token. If a public link is reported, capture its URL, visible filters and response before removing it, then review other links created by the same account. The useful security boundary is the combination of role, key and share scope.
Top comments (0)