Rocket.Chat combines a web workspace, REST APIs, personal access tokens, integrations, and a permission system. A public login page is a visible product signal. It does not reveal which API routes are enabled, which roles can list users, or whether a personal access token remains valid after an account change. An exposure review should connect the external host to the workspace settings and the API permission model.
The November 8, 2026 ZoomEye count-only snapshot used sub_type=all, page 1, and page size 1. app="Rocket.Chat" returned 2,150 assets. title="Rocket.Chat" returned 24,540. http.body="Rocket.Chat" returned 781,078. These counts describe different query populations. The body query is broad and can match documentation, community pages, and product references. The app and title results are more useful for product candidates but still require ownership and configuration confirmation.
Rocket.Chat's permission settings documentation includes granular controls for REST API behavior, including settings that affect broad user listing and result counts. Those controls exist because an API can expose more than the login page suggests. A workspace with default roles, a permissive integration, or a legacy API setting may allow a user to enumerate objects that the UI does not emphasize. Reviewing only the sign-in page will miss that layer.
Personal access tokens need a registry. For each token, record the user, workspace, creation time, last use, scope or effective permissions, and the client that depends on it. The documentation notes that an admin can deactivate a user, which should be part of a revocation test. Rotate tokens after role changes and remove tokens that belong to deactivated accounts. Do not treat a successful token revocation as proof that every browser session or OAuth grant is gone.
SSO and third-party identity add another lifecycle path. A workspace may use SAML, OAuth, or a custom iframe flow. Account removal should revoke local sessions and tokens in addition to disabling the identity-provider login. Test a user who signs in through SSO, obtains a personal token, and then loses the SSO account. Confirm whether the token still works and whether the workspace owner receives an alert.
The API permission review can start with high-value endpoints: user listing, room membership, file access, integration management, and settings changes. Map each endpoint to a role and to an explicit business need. Review any setting that permits bypasses or removes normal result limits. Apply rate limits and monitoring so a permitted user cannot turn a read endpoint into a bulk export without detection.
External discovery should use the app and title queries to build candidates, then compare the hostnames with DNS and the internal chat inventory. A candidate may be a login page for a customer workspace or a page about Rocket.Chat. Use authorized metadata and response headers to classify it. Do not send unsolicited login attempts or enumerate APIs against a third party.
Rocket.Chat is designed to be extensible, so its authorization surface is larger than a simple chat login. The security review should include tokens, integrations, role settings, and API limits. ZoomEye shows where product-like assets appear and how query choice changes the population. The internal permission model determines whether a visible workspace can disclose data beyond its intended audience.
Query evidence
Collection: 2026-11-08 00:44 UTC, ZoomEye SDK,
sub_type=all, page 1, page size 1.app="Rocket.Chat": 2,150.title="Rocket.Chat": 24,540.http.body="Rocket.Chat": 781,078.