Bearer read-scope API keys bypass ticket visibility entirely — confirm this is an intentional, documented decision #70

New Issue

2026-09-01T00:07:09-04:00

jared commented

2026-09-01 00:07:09 -04:00

Severity: High (design decision requiring explicit confirmation, not necessarily a bug)

api/tickets_api.php — both the single-ticket read path (ticketModel->getTicketById($ticketId), no canUserAccessTicket() call) and the list/triage path ($user passed as null, so TicketModel::getAllTickets()'s visibility filter is skipped entirely per its own logic) bypass the app's entire visibility subsystem. There's an existing code comment explaining this is intentional ("trusted server credential, not an end user").

Concern: Per the README and admin UI, a read-scope API key can be generated for any external tool, not just hwmonDaemon — there's no way to scope a key to public-visibility-only tickets. Any read-scope key, however it's issued or to whomever, gets blanket read access to Confidential-visibility ticket titles, descriptions, and comments. If a key is ever handed to a less-trusted integration or third party, this is a full confidentiality bypass with no visibility distinction in the API surface itself.

Ask: Confirm this is the intended trust model (all API keys are equally trusted regardless of scope, by design) and if so, document it explicitly in the README's API Key Management / Bearer API sections so it's not accidentally assumed to respect visibility. If it's NOT intended, consider adding an optional visibility-scoping flag when generating a key.

**Severity:** High (design decision requiring explicit confirmation, not necessarily a bug) `api/tickets_api.php` — both the single-ticket read path (`ticketModel->getTicketById($ticketId)`, no `canUserAccessTicket()` call) and the list/triage path (`$user` passed as `null`, so `TicketModel::getAllTickets()`'s visibility filter is skipped entirely per its own logic) bypass the app's entire visibility subsystem. There's an existing code comment explaining this is intentional ("trusted server credential, not an end user"). **Concern:** Per the README and admin UI, a `read`-scope API key can be generated for *any* external tool, not just hwmonDaemon — there's no way to scope a key to public-visibility-only tickets. Any `read`-scope key, however it's issued or to whomever, gets blanket read access to Confidential-visibility ticket titles, descriptions, and comments. If a key is ever handed to a less-trusted integration or third party, this is a full confidentiality bypass with no visibility distinction in the API surface itself. **Ask:** Confirm this is the intended trust model (all API keys are equally trusted regardless of scope, by design) and if so, document it explicitly in the README's API Key Management / Bearer API sections so it's not accidentally assumed to respect visibility. If it's NOT intended, consider adding an optional visibility-scoping flag when generating a key.

jared added the needs-decision priority/high security labels 2026-09-08 10:15:47 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: LotusGuild/tinker_tickets#70