Papercups Live Chat Sits on Customer Identity and API Tokens
Papercups is a self-hosted customer messaging and live-chat platform. It is designed to put a small widget in front of a public website while keeping conversations on infrastructure the operator controls. That architecture creates two very different surfaces: a customer-facing chat entry point that must accept messages from visitors, and an operator-facing API and dashboard that must expose only the right conversations to the right staff.
The ZoomEye measurement on 15 November 2026 returned 0 matches for app="Papercups", 68 for title="Papercups", and 834 for http.body="papercups" with sub_type=all, page 1, and page size 1. The body query is broad and may include documentation or package references. The title count is a discovery signal, not proof that every result is a live Papercups deployment.
Separate the widget from the control plane
The public widget has to be reachable without an operator API key. It should accept only the fields the conversation workflow needs, enforce message and attachment limits, and bind the browser session to a conversation without trusting a customer-supplied identity blindly. The operator REST API uses a bearer token according to the project's API documentation. That token belongs to the control plane and should not be embedded in the public widget.
Review agent invitations, role changes, inbox assignment, and conversation export. A chat system usually contains names, email addresses, free-form messages, and sometimes uploaded files. Authorization should be tested with two agents who can see different inboxes, an agent who has lost access, and a widget visitor who guesses a conversation identifier.
The realtime WebSocket path needs the same checks as the REST API. Confirm that the connection authenticates before subscribing, that room or conversation identifiers are not accepted as authorization claims, and that origin checks do not replace server-side authorization. A public socket endpoint can be intentionally reachable while still rejecting unauthorized subscriptions.
Inventory the retained data
Record the deployment URL, application version, API token owner, number of active agents, storage backend, retention rule, and public widget origins. Check whether the server is behind TLS and whether the reverse proxy preserves the real client address without letting an untrusted client set it. The operator should know where transcripts and attachments are stored and who can export them.
Papercups is small enough that a title search may be the only product clue visible from outside. That does not turn the count into a vulnerability finding. The appropriate next step is owner confirmation and an authenticated configuration review, not a request to a customer conversation endpoint.
Top comments (0)