Zammad Exposure Reviews Need to Include API and Customer Data Paths
Zammad Exposure Reviews Need to Include API and Customer Data Paths A helpdesk platform receives customer messages, identities, attachments, and support history. Zammad can expose a user interface, agent workflows, cus
Zammad Exposure Reviews Need to Include API and Customer Data Paths
A helpdesk platform receives customer messages, identities, attachments, and support history. Zammad can expose a user interface, agent workflows, customer-facing pages, and an API. An internet-facing helpdesk may be intentional, but the access review still needs to establish who can read tickets, which external authentication is active, and whether API tokens inherit the right permissions.
Zammad supports two-factor authentication for user accounts [1]. Its API documentation describes multiple authentication methods, and the system documentation provides guidance for API tokens and session behavior [2]. The exact interface an organization uses can differ from the default. A customer portal may need unauthenticated access to create a ticket, while the agent interface and API should remain restricted. The security decision should follow the data and action available on each path.
On 2026-10-29 at 19:45 UTC, ZoomEye returned 12,443 matches for app="Zammad" and 4,883 for title="Zammad". Both probes used sub_type=all, page 1, and pagesize=1; the SDK response supplied the matched totals [3]. The application query is preserved in the link [4]. The two counts differ by 7,560 in this observation. The larger application set is not proof of a public helpdesk or an exposed API. It is a candidate population that needs route and configuration evidence.
Start the review with an owner and a data classification. Determine whether tickets contain personal data, authentication secrets, payment data, or sensitive attachments. Then inventory the public portal, agent UI, admin UI, API, webhook endpoints, mail channels, and identity provider. Record which hostnames and paths are public, which are restricted to staff, and which send data to third parties.
Authentication needs role-level testing. Confirm that a customer cannot access another customer's ticket, that an agent cannot change administrative settings, and that a read-only agent cannot download attachments outside the assigned group. Test API tokens separately. A token should have a clear owner, purpose, scope, and revocation path. When an account is disabled at the identity provider, verify that existing browser sessions and API tokens are no longer usable according to the organization's policy.
Review mail and webhook integrations as data flows. A helpdesk may receive email from external senders, forward messages to a chat service, or call a webhook on ticket creation. Record the destination, credential, data fields sent, and retry behavior. Do not put API tokens in ticket templates or public knowledge-base articles. Protect attachment storage and backups with the same access policy as the ticket database.
If the helpdesk must be public, separate the customer portal from agent and administrative routes at the reverse proxy. Require MFA for privileged users, rate-limit login and ticket creation, and monitor suspicious exports, role changes, and API-token use. A customer portal login page alone does not prove that the administrative application is protected. A product match does not prove that the exposed route is the public portal rather than the agent interface.
A practical test set includes an unauthenticated request to the agent API, a customer attempting to read a ticket belonging to another customer, a revoked API token, and a role change from agent to administrator. Confirm the expected denial at the data boundary, not only at the login redirect. Repeat with a session created through the configured identity provider.
ZoomEye gives a repeatable external view of product-shaped assets. Zammad's substantive security question is about customer data access. Use the query to find candidates, validate the product and route, then combine identity, role, token, and integration evidence. The result should be a reachability and access decision that an owner can defend.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.