Komga: API Keys and Library Restrictions Need to Be Reviewed Together
Komga: API Keys and Library Restrictions Need to Be Reviewed Together Komga is a self-hosted media server, but its security surface follows the same pattern as many internal applications: users can have roles, clients
Komga: API Keys and Library Restrictions Need to Be Reviewed Together
Komga is a self-hosted media server, but its security surface follows the same pattern as many internal applications: users can have roles, clients can authenticate with API keys, and administrators can restrict which libraries a user sees. The effective access is the intersection of those controls, not the login method alone.
What the external measurement shows
On 2026-11-06 08:46:26 +08:00, ZoomEye count-only queries used sub_type=all, page 1, and pagesize 1. app="Komga" returned 1, title="Komga" returned 14,198, and http.body="Komga" returned 96,597. The title count is much larger than the application fingerprint. The body result is broad and should not be treated as deployment evidence without inspecting the matching records and attribution.
Authentication and user roles
Komga's API documentation says most endpoints require authentication. It supports HTTP Basic authentication and an API key in the X-API-Key header. Session cookies are created for credential-based login, while API-key authentication does not create a session. Admin endpoints for listing, creating, updating, and deleting users require the administrator role.
The user guide defines page streaming and file download as separate roles. An administrator can limit a user to specific shared libraries. The default is unrestricted access to all libraries, so a user account created for one collection needs an explicit review of its restrictions.
Review the effective grant
For each account, record its role, allowed libraries, content restrictions, API keys, last authentication activity, and owner. Check whether an API key belongs to an administrator, a delegated reader, or an integration. Because API keys authenticate the request directly, pair a key with a narrow user and the correct library restrictions rather than reusing an administrator for every client.
Test by logging in as a restricted user and requesting metadata, page content, and file downloads outside the allowed library. Repeat through an API key. A successful login is not enough evidence if the user can still enumerate another library or read a file through a different endpoint.
Operational response
Revoke unused keys and delete or restrict stale users. Review the reverse proxy and TLS configuration, then confirm that unauthenticated requests cannot reach administrative or file-download endpoints. Retain authentication activity long enough to support an investigation.
Use the external count to find candidate instances and verify ownership through internal records. The count does not reveal a Komga user's role or library scope. Those facts come from the controlled deployment and its audit evidence.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.