[Feature Request] Secure Native Metrics Endpoint & Read-Only API Tokens (Follow-up to #1541)

[Xyz00777]

Description

Hi everyone,

I'm writing this because the original discussion on this topic (#1541) was automatically closed, and I believe we need to revisit this from a "secure by design" perspective.

The Core Problem: Token Permissions and Security

I understand the argument that exporting data to Prometheus or similar monitoring stacks is generally the responsibility of a third-party tool. However, providing that base data securely should be a core Paperless responsibility.

Currently, to get instance-wide metrics, you have to give a service user full Administration permissions. This is a major security risk. If that monitoring service or token is compromised, the attacker can see, edit, and delete all documents across the system. I don't even like creating a token on my own standard user account to check metrics, because currently, tokens mirror 100% of the user's permissions and can edit/delete documents.

Proposed Solutions:

To fix this and make monitoring secure by design, I think there are a few ways to provide the needed information safely:

1. General Metrics Endpoint: Provide a general metrics endpoint that outputs high-level system information (total amount of documents, tags, correspondents, workflows, storage paths, etc.). Fetching this should not require admin permissions, just a standard login or scoped token.
2. Per-User Metrics Breakdown: For accounts with special view privileges, the endpoint should be able to provide the data from point 1 broken down per user. For example, it would show that User A has 20 documents and 5 tags, while User B has 40 documents and 30 tags.
3. Detailed Usage Stats: If we want to take it a step further, it would be great to see how often specific tags, correspondents, or storage paths are used across the documents by a user.
4. Read-Only / Scoped API Tokens: If a standard user wants to fetch their own metrics, they should be able to create a token with only "view" permissions. The current way tokens are handled on user level violates the principle of least privilege, as they inherit everything even when the user wouldn't want that.

Performance / Implementation Idea:

To make sure this doesn't impact system performance, the endpoint doesn't need to calculate everything live. The metric statistics could be event-driven, generated when the endpoint is fetched, or just updated periodically (e.g., once a day), which could be an administrator-defined option.

But all in all, it should not be possible for a simple metrics tool to view login credentials of users (like email passwords) or the actual document contents or names with a view token alone. I'd love to hear your thoughts on picking this up again.

Thanks in advance
Xyz00777

Other

No response