DEV Community

yutianle
yutianle

Posted on

OpenReplay session data needs an access boundary review

#zoomeye #zoomeye10openreplay

OpenReplay session data needs an access boundary review

OpenReplay is an open-source session-replay and product-analytics stack. A self-hosted deployment may capture screens, interactions, console logs, and application state during a user session. That makes the replay store more sensitive than an ordinary analytics count.

Observation

At 08:42 on November 4, 2026 (UTC+8), a count-only ZoomEye SDK query with sub_type=all, page 1, and pagesize 1 returned zero application matches for app="OpenReplay" and 321 title matches for title="OpenReplay". The title matches may include documentation and non-production pages. They do not establish that session recordings are exposed.

Access paths

The official API documentation describes authentication and an instance API base URL for both hosted and self-hosted deployments. The project documentation describes role-based access with Owner, Admin, and Member roles plus SSO support in some editions. These are separate controls: an API credential and a dashboard role can both reach session data through different paths.

Start by separating collection, storage, and playback. The instrumentation endpoint receives events. Storage holds the raw replay material. The dashboard and API allow people or integrations to search and export it. A network control that protects only the dashboard leaves the ingest and API paths to review separately.

An access review should list every organization, project, role, API key, and SSO mapping that can view a session. Members should not be able to export recordings from projects they do not support. A service account used for observability should have a narrow purpose and a documented rotation date.

Review controls

Recommended controls include:

  • Confirm that session capture is disabled on sensitive forms or masked by policy.
  • Review Owner and Admin accounts and their identity-provider mappings.
  • Inventory API keys and test revocation across dashboard and export routes.
  • Verify retention and deletion behavior for recordings and derived data.
  • Check that logs do not reproduce replay URLs or authorization headers.
  • Test object-level access between projects with separate accounts.

The 321 title matches are a useful candidate queue for ownership and deployment checks. They should not be described as exposed session stores. A public title can be a product page, and a login screen can be the intended boundary.

OpenReplay's value is also its risk: it helps teams reproduce user problems by showing what happened. The same detail can reveal personal data, internal identifiers, or application state. Treat the service as a sensitive evidence system. Pair external ZoomEye visibility with an internal inventory of roles, SSO groups, API keys, masking rules, and retention.

Use the query link to repeat the title observation later. Record the exact time and scope, then compare it with the approved host inventory. This creates a defensible asset record without claiming more than the count supports.

References

Top comments (0)