Plausible team-scoped keys narrow analytics access
Plausible team-scoped keys narrow analytics access Plausible's Stats API is a read-only HTTP interface for historical and real-time analytics. The documentation says an API key is scoped to one team. A key created unde
Plausible team-scoped keys narrow analytics access
Plausible's Stats API is a read-only HTTP interface for historical and real-time analytics. The documentation says an API key is scoped to one team. A key created under a team does not inherit access to every site its owner can view across the account, and guest viewers or guest editors cannot create a key for a client's site. Those details turn analytics keys into a useful case study in effective scope.
On 2026-11-05, a count-only ZoomEye query with sub_type=all, page 1 and page size 1 returned 46 matches for title="Plausible Analytics". The exact title query returned 28, while app="Plausible Analytics" returned 0. A broad title="Plausible" query returned 9,544, but the word is common enough that it is not a reliable product count. The measurements show why title evidence should be qualified.
Read the key scope, not only the account role
An analytics API can expose page paths, referrers, countries, devices, goals and other behavioral data. Even read-only access can reveal customer names in URLs, campaign structure and traffic changes. Plausible's Stats API key is bound to the selected team and can query sites owned by that team. Review which team the key belongs to, which sites it can reach and which user created it.
Use separate keys for reporting systems, customer dashboards and ad hoc analysis. Grant the minimum team role that can create the needed key. A viewer who cannot create a key may still see data in the UI; that does not make the key a general account credential. Store it on the server and mask it in logs. Rotate on a defined schedule and after personnel changes.
Public dashboard visibility is a separate setting. Plausible documents that a site owner can make stats public to anyone with the dashboard link. Review the visibility setting alongside the key inventory. A public dashboard link can expose the same class of metrics without an API key, and access does not necessarily stop when an employee leaves.
Verify team and site boundaries
Create test requests for a site in the intended team and for a site in another team. Confirm that the second request is rejected, not merely empty because the date range has no events. Check the role of the key owner when the key was created. If the owner later moves teams, verify whether existing keys retain their original scope or require rotation.
Protect the team management interface with MFA where available and limit who can create or delete sites. Site provisioning API keys should be separate from read-only Stats API keys. Put rate limits and anomaly alerts on API use, especially around bulk exports or repeated queries against sensitive domains. Encrypt analytics exports at rest and remove stale copies.
The ZoomEye values are application-surface observations. The broad title count should not be reported as a count of vulnerable or unauthenticated Plausible installations. Use the product-name and exact-title results to prioritize verification, then confirm the deployment's own authentication and team policy.
If a key leaks, delete it and inspect API access for the affected team. Compare the requested site IDs with the team's allowed site list. The key's team scope may have limited the damage, which is exactly why explicit scope is more useful than a single all-account credential.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes โ full credit and traffic to the original publisher.