Matomo token_auth placement decides where secrets leak

Matomo uses token_auth for Reporting API calls, authenticated Tracking API requests and embedded widgets. The token is not just an analytics-read key. Matomo's documentation compares it to a user's password and explains that a token can be sent in a GET query string or a POST body. The HTTP method therefore changes where the secret can appear in logs, browser history, proxies and support bundles.

On 2026-11-05, a count-only ZoomEye query with sub_type=all, page 1 and page size 1 returned 30,589 matches for app="Matomo". The title query returned 34,688. These counts locate application surfaces, not installations with weak tokens or exposed reports.

Matomo 6 documentation adds a token access level and an "Only allow secure requests" option. A secure token is accepted only in POST requests, not as a URL parameter. The option is useful only when the integration can actually use POST. A tracking proxy or third-party connector that hardcodes GET may fail after the restriction, so test the integration before enforcing it.

Map token authority before rotation

The Reporting API documentation advises creating a dedicated user for Tracking API work and granting only the required website permission. Do that for reporting jobs as well. A token used to read one site's reports should not inherit administration of every site. If Matomo's token model provides a narrower access level, test it against the exact API methods in use. Older documentation notes that some token versions share the user's permissions; the deployment version and plugin set matter.

Search application code and configuration for token_auth passed as a query parameter. Replace it with POST body or an approved OAuth flow where available. Never put a token in a public dashboard URL or share a copied report link without checking the query string. Treat logs, HAR files and browser history as secret-bearing evidence when a token was used in a URL.

Use HTTPS and a trusted reverse proxy. Redact query strings at the proxy where possible, but do not rely on redaction as the only control because access logs may be duplicated across systems. Restrict Matomo administration to an internal network or SSO-protected gateway. Keep the dashboard and the tracking endpoint on separate hostnames if that simplifies policy.

If a token is exposed, regenerate it first, then inspect reports and administration changes made during the window. Review plugin access and saved segments that could expose another site's data. Matomo recommends two-factor authentication in its security guidance, but MFA does not protect a bearer token that has already been copied.

The ZoomEye count is not evidence of compromise. It is a reason to verify the login page, API endpoints, token transport and public reporting configuration on owned instances. The useful defensive decision is to make the secret's transport and permission scope explicit for each integration.

References

• Matomo token_auth FAQ
• Matomo Reporting API authentication
• Matomo security overview
• ZoomEye app="Matomo" observation